NinjaPigeonHit
- NinjaPigeonHit
- JIRAUSER487895
- Europe/Stockholm
- Yes
- No
MCPE-103544
Moving Blocks arenot reliable
Moving Blocks are Unreliable
Blocks moved by pistons, also known as moving blocks, are immovable. Once the moving blocks get to their desired destination, they become a regular block again, and are movable. This is where the problem occurs. Sometimes the block can be moved again 2 gameticks (1 redstone tick) after the first piston moves the block, other times it takes 4 gameticks (2 redstone ticks) after the first piston moves the block, and if powered with a short redstone pulse, there is a random chance that the block does not get moved at all.
How to reproduce:
- Have a normal piston extend a block in front of another normal piston, and have a repeater with 1 redstone tick delay going into that second normal piston. This needs to be activated by an observer, or with a redstone pulse of similar length to an observer pulse.
Expected result: It will reliably push the block 2 gameticks (1 redstone tick) after the first piston begins extending.
Actual result: The block will sometimes be moved again 2 gameticks (1 redstone tick) after the first piston begins extending, other times the block will not be moved at all, there is a random chance for either outcome.
Blocks moved by pistons, also known as moving blocks, are immovable. Once the moving blocks get to their desired destination, they become a regular block again, and are movable. This is where the problem occurs. Sometimes the block can be moved again 2 gameticks (1 redstone tick) after the first piston moves the block, other times it takes 4 gameticks (2 redstone ticks) after the first piston moves the block, and if powered with a short redstone pulse, there is a random chance that the block does not get moved at all.
How to reproduce:
1. Place a normal piston (henceforth known as the first piston) and a block in front of the first piston. Then place another piston 2 blocks away with a 1 block offset (henceforth known as the second piston). The second piston will be facing into the area where the block is pushed to, not where the block already is. Build all of this within the same chunk. If you are confused how to build this, copy Example 1.png in attachments. Another setup that will produce the same result is Example 4.png.
2. Put a repeater on 1 redstone tick of delay facing into the second piston.
3. Put a block next to the first piston and the repeater, then place an observer behind this block.
4. Update the observer.Observed Results:
The block will randomly either be pushed or not pushed by the second piston.Expected Result:
The block will always be pushed by the second piston.
Pistons begin activating 1 gametick after they are powered (setup to show this attached below). Timing like this do not follow the timings of other consumers, such as rails, trapdoors, doors, and fence gates, which activate in the same tick they are powered (setup to show this below).
To reproduce pistons not firing until 1 gametick after being powered, place 1 sticky piston with a block in front, and two repeaters, one pointing into the piston, and one pointing into the block. When they are powered the redstone dust on the other side does fire (but doesn’t visually update, because it’s a 1 gametick pulse). The 1 gametick pulse shows the piston does not begin activation until 1 gametick after being powered. (Use setup from photo1)Another way to reproduce this is having a sticky piston with a block in front which is cutting a redstone dust line, the dust under the block needs to be powered. Once the piston is activated, the dust begins powering the other side in a producer tick or 1 gametick after the piston is powered. (Use setup from photo 2)
To see that rails, trapdoors, doors, and fence gates (other consumers) activate in the same tick they are powered place a redstone dust, place a block next to it, and place a repeater on the other side of the block. The repeater powers the dust in a consumer tick first, so the dust has not visually updated yet, but the rail, trapdoor, door, and fence gate all activate in the consumer tick, or the same tick they are powered. (
Photo3)Pistons begin activating 1 gametick after they are powered (setup to show this attached below). Timing like this do not follow the timings of other consumers, such as rails, trapdoors, doors, and fence gates, which activate in the same tick they are powered (setup to show this below).
To reproduce pistons not firing until 1 gametick after being powered, place 1 sticky piston with a block in front, and two repeaters, one pointing into the piston, and one pointing into the block. When they are powered the redstone dust on the other side does fire (but doesn’t visually update, because it’s a 1 gametick pulse). The 1 gametick pulse shows the piston does not begin activation until 1 gametick after being powered. (Use setup from photo 3)Another way to reproduce this is having a sticky piston with a block in front which is cutting a redstone dust line, the dust under the block needs to be powered. Once the piston is activated, the dust begins powering the other side in a producer tick or 1 gametick after the piston is powered. (Use setup from photo 2)
To see that rails, trapdoors, doors, and fence gates (other consumers) activate in the same tick they are powered place a redstone dust, place a block next to it, and place a repeater on the other side of the block. The repeater powers the dust in a consumer tick first, so the dust has not visually updated yet, but the rail, trapdoor, door, and fence gate all activate in the consumer tick, or the same tick they are powered. (Use setup from photo 1)
These two bugs are different, this bug is regarding java parity with tree growth requirements, and logs blocking tree growth. The other "bug" that this is a "duplicate" of is suggesting changing all tree growth requirements, to be a 1 by 1 area, which is disparity, and far different from what this bug is asking
There was a problem I saw in your video, in the clips where you showed oak being grown next to the logs and pistons, that is not oaks normal growth requirements, it is a random chance that they will grow with those blocks next to them, but if their actual growth requirements are met, it will take on average 6 bonemeal attempts with dispensers, or 1 by the player. Oak growth requirements are the same as every other tree, except oak has a chance to become a large oak tree, and has a random chance of growing next to a tower of blocks that aren't dirt air or leaves, like shown in your video. The growth requirements is a 5 by 5 crown, with a 3 by 3 base, this is the same for all small tree types, those being oak, spruce, birch, jungle, and acacia. There is no inconsistency between growing requirements beside oaks random chance at growing when next to a tower of blocks, but when next to a tower of blocks, it normally blocks a lot of growth attempts. Besides those problems, this would also be disparity with the java version.
To prevent the moving block from being movable in gametick 4, in the proposed action-observation tick system, there could be a pseudo update order created for moving blocks, where a moving block always updates before a piston does, which would allow the movingBlock to be pushed reliably on gametick 2. Also MCPE-15793 is similar behavior to the java "player input bug" that was marked Won't Fix, there is currently another bug report about the "player input bug" that is still unresolved, but the initial one was Won't Fix. So this bug is java parity. Also, could MCPE-15793 bug not be fixed by action ticks being every tick, almost like the redstone system in java, instead of an action-observation tick system.
I think sim 10 is a step in the right direction, but it was a bit too much. It was about 10-20% laggier than normal. I would suggest sim 6 or sim 8 because mobs can spawn and despawn better than they do with sim 4, but it also doesn’t load nearly as many chunks as sim 10, so it could be a happy medium between mob spawning/ despawning mechanics and performance.
This issue can also be seen if you power droppers with a redstone dust line, then power them with observers, both with no delay between activations, the update order will be different. An easy visualization of this is to do the say command in command blocks, and have them ordered to say numbers 1-15. Then, power these command blocks with a redstone dust line soft powering them. The numbers will appear in a certain order. Next soft power the command blocks with observers, no delay in between each observer. The order of the list of numbers the commands blocks say are different when observers are used. This issue is also present with droppers and other consumers.
Updated the bug report.
Yes, this still affects the current version
Yes, this issue still occurs