stacked_dynamite
- stacked_dynamite
- JIRAUSER800488
- Europe/Stockholm
- Yes
- No
MC-279809
Normal
Hopper minecarts call HopperBlockEntity.suckInItems even when they are full. This causes them to send comparator updates every tick around extracted inventories even if the cart is full.
By contrast, regular hoppers do not because they check whether they are full before trying to suck in items from above.
+Test:
+
- Build setup in the image [shulker box above hopper minecart and hopper and 2 comparator update detectors]
- Fill both hopper and hopper minecart with full item stacks [in this case 5 stacks of 64 slime blocks]
- Place item stack in shulker box [most block inventories will work]
Expected: Neither comparator update detector gets triggered - after player interaction
Actual: Hopper cart comparator update detector gets triggered constantly.Additional notes:
The fix should not patch inventory hopper arrangements which currently do send comparator updates. These include: player interaction, normal transferring, and nonempty extracted inventory + unfull hopper/hopper minecart inventories which do not result in items being transferred. Also said arrangements should also still work with hopper minecarts after the fix.
Hopper minecarts call HopperBlockEntity.suckInItems even when they are full. This causes them to send comparator updates every tick around extracted inventories even if the cart is full.
By contrast, regular hoppers do not because they check whether they are full before trying to suck in items from above.
Test:
- Build setup in the image [shulker box above hopper minecart and hopper and 2 comparator update detectors]
- Fill both hopper and hopper minecart with full item stacks [in this case 5 stacks of 64 slime blocks]
- Place item stack in shulker box [most block inventories will work]
Expected: Neither comparator update detector gets triggered - after player interaction
Actual: Hopper cart comparator update detector gets triggered constantly.Additional notes:
The fix should not patch inventory hopper arrangements which currently do send comparator updates. These include: player interaction, normal transferring, and nonempty extracted inventory + unfull hopper/hopper minecart inventories which do not result in items being transferred. Also said arrangements should also still work with hopper minecarts after the fix.
Hopper minecarts call HopperBlockEntity.suckInItems even when they are full. This causes them to send comparator updates every tick around extracted inventories even if the cart is full.
By contrast, regular hoppers do not because they check whether they are full before trying to suck in items from above.
Test:
- Build setup in the image [shulker box above hopper minecart and hopper and 2 comparator update detectors]
- Fill both hopper and hopper minecart with full item stacks [in this case 5 stacks of 64 slime blocks]
- Place item stack in shulker box [most block inventories will work]
Expected: Neither comparator update detector gets triggered - after player interaction
Observed: Hopper cart comparator update detector gets triggered constantly.Additional notes:
The fix should not patch inventory hopper arrangements which currently do send comparator updates. These include: player interaction, normal transferring, and nonempty extracted inventory + unfull hopper/hopper minecart inventories which do not result in items being transferred. Also said arrangements should also still work with hopper minecarts after the fix.
Hopper minecarts call HopperBlockEntity.suckInItems even when they are full. This causes them to send comparator updates every tick around extracted inventories even if the cart is full.
By contrast, regular hoppers do not because they check whether they are full before trying to suck in items from above.
Test:
- Build setup in the image [shulker box above hopper minecart and hopper and 2 comparator update detectors]
- Fill both hopper and hopper minecart with full item stacks [in this case 5 stacks of 64 slime blocks]
- Place item stack in shulker box [most block inventories will work]
Expected: Neither comparator update detector gets triggered - after player interaction
Observed: Hopper cart comparator update detector gets triggered constantly.Additional notes:
The fix should not patch inventory hopper arrangements which currently do send comparator updates. These include: player interaction, normal transferring, and nonempty extracted inventory + unfull hopper/hopper minecart inventories which do not result in items being transferred. Also said arrangements should also still work with hopper minecarts after the fix.
This bug likely affects many more versions than currently listed.
Hopper minecarts call HopperBlockEntity.suckInItems even when they are full. This causes them to send comparator updates every tick around extracted inventories even if the cart is full.
By contrast, regular hoppers do not because they check whether they are full before trying to suck in items from above.
Test:
- Build setup in the image [shulker box above hopper minecart and hopper and 2 comparator update detectors]
- Fill both hopper and hopper minecart with full item stacks [in this case 5 stacks of 64 slime blocks]
- Place item stack in shulker box [most block inventories will work]
Expected: Neither comparator update detector gets triggered - after player interaction
Observed: Hopper cart comparator update detector gets triggered constantly.Additional notes:
The fix should ideally be an isFull check before MinecartHopper.suckInItems() is called. This will likely also reduce lag in cases where hopper minecarts are full, most frequently being hopper minecarts in 2x hopper speed box unloaders.
The fix should not patch inventory hopper arrangements which currently do send comparator updates. These include: player interaction, normal transferring, and nonempty extracted inventory + unfull hopper/hopper minecart inventories which do not result in items being transferred. Also said arrangements should also still work with hopper minecarts after the fix.
This bug likely affects many more versions than currently listed.
Hopper minecarts call HopperBlockEntity.suckInItems even when they are full. This causes them to send comparator updates every tick around extracted inventories even if the cart is full.
By contrast, regular hoppers do not because they check whether they are full before trying to suck in items from above.
Test:
- Build setup in the image [shulker box above hopper minecart and hopper and 2 comparator update detectors]
- Fill both hopper and hopper minecart with full item stacks [in this case 5 stacks of 64 slime blocks]
- Place item stack in both shulker boxes [most block inventories will work]
Expected: Neither comparator update detector gets triggered - after player interaction
Observed: Hopper cart comparator update detector gets triggered constantly.Additional notes:
The fix should ideally be an isFull check before MinecartHopper.suckInItems() is called. This will likely also reduce lag in cases where hopper minecarts are full, most frequently being hopper minecarts in 2x hopper speed box unloaders.
The fix should not patch inventory hopper arrangements which currently do send comparator updates. These include: player interaction, normal transferring, and nonempty extracted inventory + unfull hopper/hopper minecart inventories which do not result in items being transferred. Also said arrangements should also still work with hopper minecarts after the fix.
This bug likely affects many more versions than currently listed.
This bug is caused by the updates now in baseRailBlock affectNeighborsAfterRemoval no longer getting called whenever powered/activator rails change state due to changes in how levelChunk setBlockState works
The old update order is:
Block updates around 1 block above (if sloped), Block updates around rail, Block updates 1 block below, - from what is now in affectNeighborsAfterRemoval
Block updates around rail [not usually observed], Shape updates around rail - from level setBlock with flag 3
Block updates around 1 block below; Block updates around 1 block above (if sloped) - from poweredRailBlock updateState [both not usually observed]
The 25w02a update order is:
Block updates around rail, Shape updates around rail - from level setBlock with flag 3
Block updates around 1 block below; Block updates around 1 block above (if sloped) - from poweredRailBlock updateState
The fix should ideally result in the following order: (Assuming the 2nd set of updates is not useful which I do not recall it is)
Block updates around 1 block above (if sloped), Block updates around rail, Block updates around 1 block below followed by Shape updates
If the 2nd set of updates do matter, then refer to the old update order detailed above.
[For image: Lowest is cmd block 1, Highest cmd block is 3; Expected is 3, 2, 1]