Cody Wilson
- Bluenade
- bluenade
- Europe/Stockholm
- Yes
- No
MC-141113
If a piston is unable to push but is still powered, the piston doesn't remember that it is being 'powered'. so when an additional redstone signal is given through a block (i.e. another redstone line powers the piston through a block) the piston will update itself, despite the fact the the piston was already 'powered' (even though it was unable to push).
How To Replicate:
Place a block with two levers attached. Place a piston next to that block facing away. Place another block in front of the piston. Lastly, place a furnace in front of the last block and THEN flick one of the levers.
Your setup should look like this:
Destroy the furnace. The piston should stay retracted.
What i expected: flicking the other lever should NOT update the piston as it is 2 blocks away and the piston is already powered.
What happened: flicking the other lever results in the piston updating and extending.
The piston should still be in a 'powered' state, but yet it still re-powers. even whan that source is from 2 blocks away.
If a piston is unable to push but is still powered, the piston doesn't remember that it is being 'powered'. so when an additional redstone signal is given through a block (i.e. another redstone line powers the piston through a block) the piston will update itself, despite the fact the the piston was already 'powered' (even though it was unable to push).
How To Replicate:
Place a block with two levers attached. Place a piston next to that block facing away. Place another block in front of the piston. Lastly, place a furnace in front of the last block and THEN flick one of the levers.
Your setup should look like this:
Destroy the furnace. The piston should stay retracted.
What i expected: flicking the other lever should NOT update the piston as it is 2 blocks away and the piston is already powered.
What happened: flicking the other lever results in the piston updating and extending.
The piston should still be in a 'powered' state, but yet it still re-powers. even whan that source is from 2 blocks away.
If a piston is unable to push but is still powered, the piston doesn't remember that it is being 'powered'. so when an additional redstone signal is given through a block (i.e. another redstone line powers the piston through a block) the piston will update itself, despite the fact the the piston was already 'powered' (even though it was unable to push).
How To Replicate:
Place a block with two levers attached. Place a piston next to that block facing away. Place another block in front of the piston. Lastly, place a furnace in front of the last block and THEN flick one of the levers.
Your setup should look like this:
Destroy the furnace. The piston should stay retracted.
What i expected: flicking the other lever should NOT update the piston as it is 2 blocks away and the piston is already powered by the other lever.
What happened: flicking the other lever results in the piston updating and extending.
The piston should still be in a 'powered' state, but yet it still re-powers. even whan that source is from 2 blocks away.
If a piston is unable to push but is still powered, the piston doesn't remember that it is being 'powered'. so when an additional redstone signal is given through a block (i.e. another redstone line powers the piston through a block) the piston will update itself, despite the fact the the piston was already 'powered' (even though it was unable to push).
How To Replicate:
Place a block with two levers attached. Place a piston next to that block facing away. Place another block in front of the piston. Lastly, place a furnace in front of the last block and THEN flick one of the levers.
Your setup should look like this:
Destroy the furnace. The piston should stay retracted.
What i expected: flicking the other lever should NOT update the piston as it is 2 blocks away and the piston is already powered by the
otherlever.What happened: flicking the other lever results in the piston updating and extending.
The piston should still be in a 'powered' state, but yet it still re-powers. even whan that source is from 2 blocks away.
If a piston is unable to push but is still powered, the piston doesn't remember that it is being 'powered'. so when an additional redstone signal is given through a block (i.e. another redstone line powers the piston through a block) the piston will update itself, despite the fact the the piston was already 'powered' (even though it was unable to push).
How To Replicate:
Place a block with two levers attached. Place a piston next to that block facing away. Place another block in front of the piston. Lastly, place a furnace in front of the last block and THEN flick one of the levers.
Your setup should look like this:
Destroy the furnace. The piston should stay retracted.
What i expected: flicking the other lever should NOT update the piston as it is 2 blocks away and the piston is already powered by the first lever.
What happened: flicking the other lever results in the piston updating and extending.
The piston should still be in a 'powered' state, but yet it still re-powers. even whan that source is from 2 blocks away.
Block loot tables that used to work perfectly fine in previous snapshots have stopped working. The blocks no longer drop anything.
Block loot tables that used to work perfectly fine in previous snapshots have stopped working. The blocks no longer drop anything.Tile Drops was off. disregard all of this
Description
Non-shield items (given the same components as a shield) exhibit an incorrect orientation and position in first-person when blocking.
How to Reproduce
1) give yourself a shield
2) give yourself a non-shield item (like a stick) with the item_model component set to 'shield' and the blocks_attacks component enabled.
/give @s stick[item_model=shield,blocks_attacks={}]
3) hold and use both items, comparing the difference in shield model placement on-screen in first person while blocking.
Expected Result
Given that they share the same item model, the non-shield item (or "fake" shield) should appear in the same position and orientation when blocking as a real shield.
Observed Result
The "fake" shield has an incorrect orientation and position on-screen compared to the "real" shield. The fake shield appears to be facing downwards and
Description
Non-shield items (given the same components as a shield) exhibit an incorrect orientation and position in first-person when blocking.
How to Reproduce
1) give yourself a shield
2) give yourself a non-shield item (like a stick) with the item_model component set to 'shield' and the blocks_attacks component enabled.
/give @s stick[item_model=shield,blocks_attacks={}]
3) hold and use both items, comparing the difference in shield model placement on-screen in first person while blocking.
Expected Result
Given that they share the same item model, the non-shield item (or "fake" shield) should appear in the same position and orientation when blocking as a real shield.
Observed Result
The "fake" shield has an incorrect orientation and position on-screen compared to the "real" shield. The fake shield appears to be facing downwards and
Description
Non-shield items (given the same components as a shield) exhibit an incorrect orientation and position in first-person when blocking.
How to Reproduce
1) give yourself a shield
2) give yourself a non-shield item (like a stick) with the item_model component set to 'shield' and the blocks_attacks component enabled.
/give @s stick[item_model=shield,blocks_attacks={}]
3) hold and use both items, comparing the difference in shield model placement on-screen in first person while blocking.
Expected Result
Given that they share the same item model, the non-shield item (or "fake" shield) should appear in the same position and orientation when blocking as a real shield.
Observed Result
The "fake" shield has an incorrect orientation and position on-screen compared to the "real" shield. The fake shield appears to be facing downwards and offset down.
i can unfortunately confirm this is still here even in 18w20c
this has never been a thing but i still hope it gets fixed
Wont fix? That is a massive shame. Was really hoping this would be fixed over the coming snapshots. It's going to be a massive pain trying to work around this. :/