vktec
- vktec
- vktec
- Europe/London
- Yes
- No
![[Mojang] Ulraf](../../../data/avatars/users/43122.png){kind=small}
![[Mojang] Felix Jones](../../../data/avatars/users/40484.png){kind=small}
MC-171983
When standing on top of a honey block, it pulls and pushes entites as expected. However, when next to the block, entities are not moved.
To reproduce:
- Place an armor stand next to a honey block and push it one pixel into the honey block using a piston attached to a
fence post.- Push the honey block with another honey block attached to a sticky piston. The armor stand will not be moved, despite being inside the block.
When standing on top of a honey block, it pulls and pushes entites as expected. However, when next to the block, entities are not moved.
To reproduce:
- Place an armor stand next to a honey block and push it one pixel into the honey block using a piston attached to a block.
- Push the honey block with another honey block attached to a sticky piston. The armor stand will not be moved, despite being inside the block.
The chunk boundary display toggled by F3+
Qrenders on top of blocks it should be behind.The chunk boundary display toggled by F3+G renders on top of blocks it should be behind.
In 1.15.2 and below, comparators reading containers through blocks would output the container's signal strength unless the signal strength of the block was 15, in which case they would output signal strength 15. In 20w06a, this changed and comparators will now output the highest of the two signal strengths.
This feature
is very useful in 1-wide tileable contraptions, where it can be used to detect full containers, etc.In 1.15.2 and below, comparators reading containers through blocks would output the container's signal strength unless the signal strength of the block was 15, in which case they would output signal strength 15. In 20w06a, this changed and comparators will now output the highest of the two signal strengths.
This feature was very useful in 1-wide tileable contraptions, where it can be used to detect full containers, etc.
Still getting this with cauldrons in 1.14.4
I'd urge you to reconsider on the "works as intended" resolution. This was the one thing, other than the possibility of not sticking to slime, that made honey interesting to me. If both of these are "works as intended", honey is fairly uninteresting as far as redstone is concerned.
One simple method to make redstone wire update in a more predictable manner would simply be to stop using the `toUpdate` field of `net.minecraft.world.level.block.RedStoneWireBlock`: instead of adding the positions to be updated to a set which is later iterated over and then cleared (note that the only uses of `toUpdate` are in `updatePowerStrength` and `updatePowerStrengthImpl`), simply update the positions as they are found - call `Level.updateNeighborsAt` once with the position of the dust, then once per Direction, utilizing the loop in `updatePowerStrengthImpl` that currently adds the positions to the `toUpdate` set.
I could create a patch showing these changes, but I'm not sure how useful it would be since it's deobfuscated code, and am also unsure about whether or not it violates the EULA
Perhaps I'm misreading the code, but as I see it, updatePowerStrength and updatePowerStrengthImpl could be merged into one method, with toUpdate being a local variable (which would be slightly slower than having it as a field, my point is just that it could be done).
Since the blocks which get added to toUpdate are the same every time, and none of those will be the same as any other (they're the redstone wire block and the 4 blocks in each cardinal direction from it), I see no reason to store them in a HashSet at all.
Again, I may well be reading the code wrong and it's much more complex than I think.
I think you may be out of date. updatePowerStrengthImpl is the only place where toUpdate is modified, and performs no recursive calls that I can see. updatePowerStrength clears toUpdate directly after calling updatePowerStrengthImpl which, as you say, makes the set pointless.
There may be a hidden recursive call I'm missing, however.
Just to make sure I wasn't being an idiot, I wrote a mod using my suggested fix. It seems to work fine, but I've not done particularly extensive testing. If anyone feels like playing with it, the code is here: https://github.com/vktec/wire-order-fix
A JAR file for 1.14.4 Fabric can be downloaded from here if you don't feel like compiling it yourself: https://github.com/vktec/wire-order-fix/releases/tag/0.1.0
Experiencing this on 1.15.1-pre1 as well
That is incorrect. Mobs will spawn inside doors, with trapdoors or string inside their heads, etc.
The spawning algorithm requires a non-full block at foot and head height, as well as that the entity to be spawned will not collide with anything.
Further testing in a server I'm part of indicates this bug only occurs for 2-tall mobs - creepers, for example, can spawn with scaffolding in their head. This suggests to me that the mobs are (incorrectly) colliding with the top of the scaffolding.
This is not a bug, and occurs in 1.15.2 as well. This happens because of hopper update order, which is effectively random. Also, observers will not detect inventory changes in Java edition.
Sorry, forgot to check back on this. What I'm referring to is that piston heads have a hitbox that slightly protrudes past a 1x1 block space (to connect with the piston base) which in current stable versions will remain while the piston retracts, clipping through the back of the block, which can push entities back from the piston.
You can test this by pushing yourself up against the back of a sideways piston with a redstone block above and then removing the redstone block - in stable versions, you'll be pushed backwards slightly, whereas in snapshots you won't.
This is almost definitely WAI. If it's not, I wish it was because it's incredibly useful.
I think it was a joke