hutr2002
- hutr2002
- hutr2002
- Asia/Shanghai
- Yes
- No
Overview
When I was checking the F3 screen to get some info of the targeting block states, I found that some block states are "out of sync" with the real block states.
Related blocks are: cactus, sugar cane, saplings, hopper, dispenser and dropper.
This issue is quite annoying, at least for me, because I need to check whether my dispensers, droppers and hoppers in my contraptions function normally. In order to do this I usually check the F3 screen, but I have found that the info in the F3 screen is wrong.
I hope that the upcoming 1.15 could fix this issue.
Details
For dispenser and dropper, the <triggered> state does not change when it is powered/depowered.
For hopper, the <enable> state does not change when it is powered/depowered.
For cactus and sugar cane, the <age> state does not change when it is growing.
For sapling, the <stage> state does not change when it is growing.
More detailed information is included in the attached screenshots.
Suggestion
Having found this issue, I've checked the game code using 1.14.4 forge, and tried to find the corresponding code
inthenewest snapshot with the help of the obfuscation maps.In the code of those six blocks mentioned, the setBlock() method (net.minecraft.world.level.Level.setBlock()) is called with a flag of 4, so the changes are not sent to clients, since the 0x2 bit is 0.
Change those flags to 6 may fix this issue.
Overview
When I was checking the F3 screen to get some info of the targeting block states, I found that some block states are "out of sync" with the real block states.
Related blocks are: cactus, sugar cane, saplings, hopper, dispenser and dropper.
This issue is quite annoying, at least for me, because I need to check whether my dispensers, droppers and hoppers in my contraptions function normally. In order to do this I usually check the F3 screen, but I have found that the info in the F3 screen is wrong.
I hope that the upcoming 1.15 could fix this issue.
Details
For dispenser and dropper, the <triggered> state does not change when it is powered/depowered.
For hopper, the <enable> state does not change when it is powered/depowered.
For cactus and sugar cane, the <age> state does not change when it is growing.
For sapling, the <stage> state does not change when it is growing.
More detailed information is included in the attached screenshots.
Suggestion
Having found this issue, I've checked the game code using 1.14.4 forge, and tried to find the corresponding code of the latest snapshot with the help of the obfuscation maps.
In the code of those six blocks mentioned, the setBlock() method (net.minecraft.world.level.Level.setBlock()) is called with a flag of 4, so the changes are not sent to clients, since the 0x2 bit is 0.
Change those flags to 6 may fix this issue.






Actually, although this issue doesn't affect the gameplay, it makes creating a resourcepack to display these blockstates impossible. So I insist that it should be fixed, since many people, especially redstoners, use some kinds of "blockstate displaying resourcepack". By the way, those newly added block such as bamboo and scaffolding, or those newly added blockstates such as <distance> of leaves, do notify the client when the state changes despite the textures not changing.
It does not affect Carrots, Potatoes, Wheat and Beetroots.
Also it does not affect Bamboo Saplings.
It seems to affect those "stackable" blocks only. By saying "stackable" I mean blocks which can grow another one on top of itself.
Maybe it's an intentional behavior: when the supporting block is removed, the plants break one after another, having 1 gametick delay, rather than break all at once. Perhaps it's a kind of optimization.
Can confirm in 1.17 release