Andrew
- amh11706
- amh11706
- Europe/Stockholm
- Yes
- No
MC-11106
A sticky piston powered as in the picture below will create less than one tick pulses but the piston still holds on to the block. Powering the repeater to the left causes this.
Sticky Pistons will not drop blocks in some setups.
A sticky piston powered as in the picture below will create less than one tick pulses but the piston still holds on to the block. Powering the repeater to the left causes this. What I would expect to happen is the block to be left in the extended position as it does in nearly every other setup with 1 tick or shorter pulses.
In version 1.5.2 and before, it was possible to harvest crops planted on farmland (wheat, carrots, potatoes, etc.) by blocking all light sources. This would cause all of the crops to pop off at once as soon as any one of them received an update. In 1.6.1 and 1.6.2 pre-release, they pop off one at a time.
A crop popping off no longer triggers its neighbors to update and pop as well. I do not believe this is/should be the intended behavior because the crops still pop off with a redstone update. Upon testing with a BUD, it appears that the crops popping off due to insufficient light does not create an update at all.
I will link a video when I get it recorded.
In version 1.5.2 and before, it was possible to harvest crops planted on farmland (wheat, carrots, potatoes, etc.) by blocking all light sources. This would cause all of the crops to pop off at once as soon as any one of them received an update. In 1.6.1 and 1.6.2 pre-release, they pop off one at a time.
A crop popping off no longer triggers its neighbors to update and pop as well. I do not believe this is/should be the intended behavior because the crops still pop off with a redstone update. Upon testing with a BUD, it appears that the crops popping off due to insufficient light does not create an update at all.
If this is the case, then why does stringing a line of repeaters after the block to the right show a series of 1 on 2 off pulses? Also, the dust is graphically flickering for less than one tick.
Also happens when the plants pop off from not enough light (
MC-22874) or when a piston shifts the floor.Works as intended? Please tell me you at least checked the video... The crops are not causing a block update AT ALL when they pop off (unless you punch them), which means sand, gravel, anvils, or carpets placed on top of the crop will be left floating when the crop 'pops'. The dirt can then be removed to create floating blocks anywhere you like. Now that I look for that bug, I see it's posted and confirmed already
MC-19886but that is just a side effect of the broken crop behavior.Taiga doesn't have snow anymore, it's 'Cold Taiga" that has snow now.
2x2 jungle trees have many layers of leaves, and the 2x2 spruce has a variation with leaves all the way down so neither of them are as bad. They also have a single sapling version that helps, but the dark oak only has 2x2.
Seems to be fixed in 1.7.2, just got 11 saplings from one dark oak. Either I was incredibly unlucky before or they fixed it now
Still happens in 14w30c
In earlier versions, the piston would leave the block behind. This was quite useful as a mono stable circuit that only fires once until it gets reset (pulling the block back in). I had a segmented farm setup that took advantage of this nicely. The piston removes its power source the instant it is powered, so it should create a <1 tick pulse and leave the block behind. "Fixing" it by adding another piston isn't very practical in survival and/or compact setups.
In the new snapshots, dark oak and acacia logs, leaves, and stairs are all separated from the other wood types.
Invalid? This bug is about more than leaving the block behind or not... The idea here is that in the majority of configurations the pistons will leave blocks behind with a short pulse but in this one it will not. An inconsistency is bad regardless of which outcome was intended.
Yes, this still happens in 1.9.1-pre3. Now that the related piston report is 'works as intended' I believe we can agree this is not intended behavior