Myren Eario
- Myren
- myren
- Europe/Stockholm
- Yes
- No
MC-98197![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
Normal
If you build the contraption shown in the first picture below, and switch the lever, it will look like it duplicates the slimeblock and an iron block. The duplicate slime and iron block are ghost blocks.
There have been several other bug reports about ghost blocks. The reason I make another bug report is, that this particular method to generate ghost blocks has only started working in 1.9-pre 1. It didn´t work in 16w07b and before. So this is not supposed to be a bug report about ghost blocks in general, but instead a bug report about this particular method to create ghost blocks, which is a new bug and not a duplicate of any bug that existed before 1.9-pre 1.
Now I don´t know why the piston behavior was changed from 16w07b to 1.9-pre 1. If there´s no significant reason why it was changed, then the simplest way to fix this bug, would be to revert the changes in piston behavior, that were made from 16w07b to 1.9-pre 1. This way this ghost block generation method could be fixed very quickly and efficiently before 1.9 gets released.
When a piston is unloaded in the exact game tick he should extend or retract, he sometimes forgets to extend or retract after being reloaded.
According to the 1.
8 sourcecode decompiled with MCP, pistons don´t extend or retract immediately when they´re updated and powered/unpowered, but they just schedule a block event, that gets processed later. Block Events get processed every tick. And only once the block events get processed the piston will extend/retract. However if the game is unloaded before the block events get processed, all scheduled block events get lost, because block events don´t get saved anywhere. Therefor, if the game is unloaded, pistons sometimes don´t extend or retract, even though they should.It should be mentioned, that before 1.9 pistons that forgot to retract didn´t just stay extended, but transformed into a state that looks like the one in this bug report
MC-49981
So while the bug that pistons get into a glitchy piston state when they forget to retract was resolved, the bug that pistons sometimes forget to retract has not been resolved yet.The situations depicted in the pictures below can occur if the game is unloaded in the exact moment the piston directly next to the lever finishes his extension.
When a piston is unloaded in the exact game tick he should extend or retract, he sometimes forgets to extend or retract after being reloaded.
Video demonstrating the bug in 16w44a: https://www.youtube.com/watch?v=9bm5_fKPcDc
According to the 1.10 code decompiled with MCP, pistons don´t extend or retract immediately when they´re updated and powered/unpowered, but they just schedule a block event, that gets processed later. Block Events get processed every tick. And only once the block events get processed the piston will extend/retract. However if the game is unloaded before the block events get processed, all scheduled block events get lost, because block events don´t get saved anywhere. Therefore, if the game is unloaded, pistons sometimes don´t extend or retract, even though they should.
It should be mentioned, that before 1.9 pistons that forgot to retract didn´t just stay extended, but transformed into a state that looks like the one in this bug report
MC-49981
So while the bug that pistons get into a glitchy piston state when they forget to retract was resolved, the bug that pistons sometimes forget to retract has not been resolved yet.The situations depicted in the pictures below can occur if the game is unloaded in the exact moment the piston directly next to the lever finishes his extension.
If you place an observer block with /setblock it will always face in the positive z / south direction, independent of which additional data value you type in the /setblock command.
You can verify this by using the commands "/setblock ~ ~ ~ observer 1", "/setblock ~ ~ ~ observer 2" etc. and seeing that they all face in the same direction.If you move an observer with a piston and reload the game while the observer is moving, then the observer will face into the positive z / south direction.
You can verify this by placing down a piston, then place an observer facing upwards in front of the piston, then activate the piston and quickly relog before the piston finishes his extension. After that you will see that the observer no longer faces upwards but south.I post these two bugs in one bug report, because they´re probably related.
In 16w41a this bug has changed significantly.
Bug summary for 16w41a+:If you activate an observer by updating him, then start moving the observer while it still gives out power, and then reload the game before the observer finishes moving, then the rotation of the observer will change.
If the output of the observer was facing into the +y direction, he will rotate to face into +z.
If he was facing into +z then he´ll face into +x.
If he was facing into +x then he´ll face into +y.
Same happens with negative directions. -y goes to -z. -z goes to -x. -x goes to -y.Here´s a video demonstrating the bug:
https://www.youtube.com/watch?v=qFKHRlapufQInitial bug report (fixed in 16w41a):
If you place an observer block with /setblock it will always face in the positive z / south direction, independent of which additional data value you type in the /setblock command.
You can verify this by using the commands "/setblock ~ ~ ~ observer 1", "/setblock ~ ~ ~ observer 2" etc. and seeing that they all face in the same direction.If you move an observer with a piston and reload the game while the observer is moving, then the observer will face into the positive z / south direction.
You can verify this by placing down a piston, then place an observer facing upwards in front of the piston, then activate the piston and quickly relog before the piston finishes his extension. After that you will see that the observer no longer faces upwards but south.I post these two bugs in one bug report, because they´re probably related.
Video provided by Nicklas Ekstrand.
Observer rotatestowards +z, when reloaded while being moved or set with /setblockObserver rotates when being udpated, moved and then reloaded
In 16w41a this bug has changed significantly.
Bug summary for 16w41a+:If you activate an observer by updating him, then start moving the observer while it still gives out power, and then reload the game before the observer finishes moving, then the rotation of the observer will change.
If the output of the observer was facing into the +y direction, he will rotate to face into +z.
If he was facing into +z then he´ll face into +x.
If he was facing into +x then he´ll face into +y.
Same happens with negative directions. -y goes to -z. -z goes to -x. -x goes to -y.Here´s a video demonstrating the bug:
https://www.youtube.com/watch?v=qFKHRlapufQInitial bug report (fixed in 16w41a):
If you place an observer block with /setblock it will always face in the positive z / south direction, independent of which additional data value you type in the /setblock command.
You can verify this by using the commands "/setblock ~ ~ ~ observer 1", "/setblock ~ ~ ~ observer 2" etc. and seeing that they all face in the same direction.If you move an observer with a piston and reload the game while the observer is moving, then the observer will face into the positive z / south direction.
You can verify this by placing down a piston, then place an observer facing upwards in front of the piston, then activate the piston and quickly relog before the piston finishes his extension. After that you will see that the observer no longer faces upwards but south.I post these two bugs in one bug report, because they´re probably related.
Video provided by Nicklas Ekstrand.
Observer rotates when being udpated, moved and then reloaded
Usually when a powered rail, detector rail or activator rail gets destroyed it sends out block updates to the blocks diagonally below it.
In 17w50a, when you have a powered/detector/activator rail and you push it away with a piston, then it does not send out block updates diagonally below it.
This can cause some blocks to get into invalid states.
Pictures:
https://imgur.com/a/iJ5cCIn the first picture you see a contraption. If you flick the lever, then you get the second picture. In the second picture the powered rail on the lower block is in an invalid state because it´s on even though it is not powered by anything. That rail should have been updated when the upper powered rail was pushed away, but it wasn´t.
(If I try to directly upload the pictures to this si
de then it just says "JIRA could not attach the file as there was a missing token. Please try attaching the file again.").(Also this is not a duplicate of https://bugs.mojang.com/browse/MC-96224, because the bug I´m describing here was newly introduced in the 1.13 snapshots and didn´t exist before, while MC-96224 is older, and secondly this bug is about block updates missing when a rail starts being pushed, while MC-96224 is about block updates missing when a rail finishes being pushed).
Usually when a powered rail, detector rail or activator rail gets destroyed it sends out block updates to the blocks diagonally below it.
In 17w50a, when you have a powered/detector/activator rail and you push it away with a piston, then it does not send out block updates diagonally below it.
This can cause some blocks to get into invalid states.
Pictures:
https://imgur.com/a/iJ5cCIn the first picture you see a contraption. If you flick the lever, then you get the second picture. In the second picture the powered rail on the lower block is in an invalid state because it´s on even though it is not powered by anything. That rail should have been updated when the upper powered rail was pushed away, but it wasn´t.
(If I try to directly upload the pictures to this site then it just says "JIRA could not attach the file as there was a missing token. Please try attaching the file again.").
(Also this is not a duplicate of https://bugs.mojang.com/browse/MC-96224, because the bug I´m describing here was newly introduced in the 1.13 snapshots and didn´t exist before, while MC-96224 is older, and secondly this bug is about block updates missing when a rail starts being pushed, while MC-96224 is about block updates missing when a rail finishes being pushed).
When a falling block entity goes through an end gateway, the PortalCooldown of the entity gets set to 300.
This cooldown should be over after 15 seconds, and the falling block should be able to go through another gateway after 15 seconds,
but it actually does not do that, it never counts down its PortalCooldown, and the entity can never go through another gateway again.The issue could be resolved by calling the processPortalCooldown() method somewhere in the tick() method of the FallingBlockEntity class.
For most entities this method gets called as part of the handleNetherPortal() method, but falling block entities do not call that method because they cannot use nether portals.So basically, falling block entities do not process their PortalCooldown, because they cannot use nether portals.
But falling block entities can use end gateways, and end gateways use the exact same PortalCooldown variable, so falling block entities ought to process their PortalCooldown.
To see this behavior in-game place two gateway blocks with a cobweb inbetween in mid-air in the end,
go through the upper gateway to generate a gateway on the outer end islands, and then let a falling sand entity fall through the gateway on the outer end islands.
The falling sand entity will fall slowly through the cobwebs, and touch the lower gateway block with a delay of more than 15 seconds, but it will not go through the lower gateway.
After 30 seconds the falling sand entity will destroy itself without ever having gone through the lower gateway.
If the same experiment is done with a different entity, like for example a cow, then the cow will go through the lower gateway after 15 seconds.When a falling block entity goes through an end gateway, the PortalCooldown of the entity gets set to 300.
This cooldown should be over after 15 seconds, and the falling block should be able to go through another gateway after 15 seconds,
but it actually does not do that, it never counts down its PortalCooldown, and the entity can never go through another gateway again.The issue could be resolved by calling the processPortalCooldown() method somewhere in the tick() method of the FallingBlockEntity class.
For most entities this method gets called as part of the handleNetherPortal() method, but falling block entities do not call that method because they cannot use nether portals.So basically, falling block entities do not process their PortalCooldown, because they cannot use nether portals.
But falling block entities can use end gateways, and end gateways use the exact same PortalCooldown variable, so falling block entities ought to process their PortalCooldown.
To see this behavior in-game place two gateway blocks with a cobweb inbetween in mid-air in the end,
go through the upper gateway to generate a gateway on the outer end islands, and then let a falling sand entity fall through the gateway on the outer end islands.
The falling sand entity will fall slowly through the cobwebs, and touch the lower gateway block with a delay of more than 15 seconds, but it will not go through the lower gateway.
After 30 seconds the falling sand entity will destroy itself without ever having gone through the lower gateway.
If the same experiment is done with a different entity, like for example a cow, then the cow will go through the lower gateway after 15 seconds.
When a falling block entity goes through an end gateway, the PortalCooldown of the entity gets set to 300.
This cooldown should be over after 15 seconds, and the falling block should be able to go through another gateway after 15 seconds,
but it actually does not do that, it never counts down its PortalCooldown, and the entity can never go through another gateway again.The issue could be resolved by calling the processPortalCooldown() method somewhere in the tick() method of the FallingBlockEntity class.
For most entities this method gets called as part of the handleNetherPortal() method, but falling block entities do not call that method because they cannot use nether portals.So basically, falling block entities do not process their PortalCooldown, because they cannot use nether portals.
But falling block entities can use end gateways, and end gateways use the exact same PortalCooldown variable, so falling block entities ought to process their PortalCooldown.
To see this behavior in-game place two gateway blocks with a cobweb inbetween in mid-air in the end,
go through the upper gateway to generate a gateway on the outer end islands, and then let a falling sand entity fall through the gateway on the outer end islands.
The falling sand entity willfallslowly through the cobwebs, and touch the lower gateway block with a delay of more than 15 seconds, but it will not go through the lower gateway.
After 30 seconds the falling sand entity will destroy itself without ever having gone through the lower gateway.
If the same experiment is done with a different entity, like for example a cow, then the cow will go through the lower gateway after 15 seconds.When a falling block entity goes through an end gateway, the PortalCooldown of the entity gets set to 300.
This cooldown should be over after 15 seconds, and the falling block should be able to go through another gateway after 15 seconds,
but it actually does not do that, it never counts down its PortalCooldown, and the entity can never go through another gateway again.The issue could be resolved by calling the processPortalCooldown() method somewhere in the tick() method of the FallingBlockEntity class.
For most entities this method gets called as part of the handleNetherPortal() method, but falling block entities do not call that method because they cannot use nether portals.So basically, falling block entities do not process their PortalCooldown, because they cannot use nether portals.
But falling block entities can use end gateways, and end gateways use the exact same PortalCooldown variable, so falling block entities ought to process their PortalCooldown.
To see this behavior in-game place two gateway blocks with a cobweb inbetween in mid-air in the end,
go through the upper gateway to generate a gateway on the outer end islands, and then let a falling sand entity fall through the gateway on the outer end islands.
The falling sand entity will teleport to the upper of the two gateways we placed, and then slowly fall through the cobwebs, and touch the lower gateway block with a delay of more than 15 seconds, but it will not go through the lower gateway.
After 30 seconds the falling sand entity will destroy itself without ever having gone through the lower gateway.
If the same experiment is done with a different entity, like for example a cow, then the cow will go through the lower gateway after 15 seconds.
When a falling block entity goes through an end gateway, the PortalCooldown of the entity gets set to 300.
This cooldown should be over after 15 seconds, and the falling block should be able to go through another gateway after 15 seconds,
but it actually does not do that, it never counts down its PortalCooldown, and the entity can never go through another gateway again.The issue could be resolved by calling the processPortalCooldown() method somewhere in the tick() method of the FallingBlockEntity class.
For most entities this method gets called as part of the handleNetherPortal() method, but falling block entities do not call that method because they cannot use nether portals.So basically, falling block entities do not process their PortalCooldown, because they cannot use nether portals.
But falling block entities can use end gateways, and end gateways use the exact same PortalCooldown variable, so falling block entities ought to process their PortalCooldown.
To see this behavior in-game place two gateway blocks with a cobweb inbetween in mid-air in the end,
go through the upper gateway to generate a gateway on the outer end islands, and then let a falling sand entity fall through the gateway on the outer end islands.
The falling sand entity will teleport to the upper of the two gateways we placed, and then slowly fall through the cobwebs, and touch the lower gateway block with a delay of more than 15 seconds, but it will not go through the lower gateway.
After 30 seconds the falling sand entity will destroy itself without ever having gone through the lower gateway.
If the same experiment is done with a different entity, like for example a cow, then the cow will go through the lower gateway after 15 seconds.This experiment demonstrates that falling sand entities do not count down their PortalCooldown like other entities.
Can confirm for
- 16w39c
I think Myren Eario said once in a video that the pushed block uses the hitbox instead of the collision box.
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
Not fixed in 16w41a. Video from Myren Eario.
This looks related to
MC-73302, which was a big unintended bug, which has been fixed in 1.9. I think items bouncing off stairs was unintended, and that they don´t bounce anymore is not a bug, but a fix.This bug seems to be also related to MC-89146 .
Fixed in 1.9-pre 1
And it was probably related to: https://bugs.mojang.com/browse/MC-89119
Confirmed for 1.9.1-pre3
(at least partially confirmed; completely confirmed are the following:
Blazes killed by tamed wolves never drop any blaze rods in 1.9.1-pre3;
Spiders killed by tamed wolves never drop any spider eyes in 1.9.1-pre3;
I haven´t tested other things yet)
Just out of curiosity I would like to know how you would imagine the game works without 0 tick pulses. Basically I´m asking: What is the intended behavior?
For example the following contraption:
http://imgur.com/KPDVUL4
In the current version if you flick the lever after the repeater delay, the piston on the right will get a 0 tick pulse, and within a single gametick he will extend and then retract.
I would not know what should happen in this situation if we do not allow pistons to react to 0 tick pulses.
Do you want, that the piston on the right doesn´t react, because it´s a 0 tick pulse? That solution doesn´t work here, because if the piston on the right doesn´t extend, then the piston on the left never retracts, and then the pulse never gets turned off, which means that the pulse wouldn´t be a 0 tick pulse, which means the piston on the right should extend.
Do you want the piston to extend and wait one gametick before retracting? Well in this situation we will see the piston extending for 1 gametick, even though the redstone line is off. Now since you´ve previously said, that it is illogical if there is "a moment where you will see the piston retracting although the redstone line is ON." then you will also consider it illogical if a piston extends even though the redstone line is off. So that solution doesn´t work here either.
So what is the intended behavior in this situation? I find a 0 tick pulse in this situation quite logical.
Another note about the " you will see the piston retracting although the redstone line is ON.": This is normal piston behavior and can be recreated even without 0 tick pulses. When you retract a piston it will ignore any other pulses until it finishes its retraction. You can recreate this situation even without 0 tick pulses, by retracting a piston and powering the piston again in the next gametick. Even though the piston will be powered 1 gametick after it started to retract, it will continue to retract. You will see the piston retracting although the redstone line is on. Now you might consider this to be illogical, but this illogical part is not related to 0 tick pulses. If we "fix" 0 tick pulses (whatever that means), then this illogical part will still be in the game.
So you don´t want to "patch all 0 tick pulses", but you just want to make the update order more simple, logical, intuitive and remove all hashsets and location dependencies. This is something I completely fully support. But the stuff you´ve written in the bug report is about the "existence of 0 tick pulses in general", and I can´t consider that to be a bug. You can simplify update order and make 0 tick pulses more intuitive, and I support that, but you can´t remove the update order and all 0 tick pulses. So I won´t support "patching 0 tick pulses out of the game".
Now I think there are even more examples where 0 tick pulses are unavoidable:
Let´s look at this:
http://imgur.com/b1RqoCx
This is just like my previous example, except I added another piston on top. If I flick the lever on, the piston on top will recieve a 0 tick pulse. Now since we already established that the piston on the bottom right will react to the 0 tick pulse, I think the piston on the top should also react to the 0 tick pulse. There´s no relevant difference between the piston on the top and the piston on the bottom right, and they both get powered and depowered at the exact same moments in the update order, by the exact same piece of redstone dust, so I think they should behave in exactly the same way.
Do you agree?
If yes then we have something called a 0 tick pulse monostable.
And there are even some 0 tick monostables which actually get used which kind of work like this. For example this 0 tick monostable relies on the same principle: http://imgur.com/PnEZabk
So if you think it´s ok to keep this, then you might want to add another edit to your bug report, because the bug report makes it look like you want to remove such monostables.
Well, there´s nothing I can say against adding a gamerule.
The only thing I might want to add is, that if "the piston should pulse" is just as legit as "the piston should turn into a derp piston", then I think it would be better if the piston pulses, because if the piston turns into a derp piston then absolutely nobody is happy, while if the piston pulses, then at least some people are happy. So I would say the piston in the loop should pulse, not because of logical consistency reasons, but because of utilitarian and game design reasons.
But again, if it´s just an optional gamerule, then it´s just an optional gamerule.
It´s not entirely accurate to say that the piston completely disappears at the retraction. If a piston retracts he´ll become a block 36 for 2 gticks (Block 36 is a block which handles block movement. In setblock commands block 36 gets called "piston_extension" and in the code it gets called BlockPistonMoving). And block 36 does not have a solid top surface, which causes flower pots to pop off. Also block 36 has no visual hitbox (but he has a collision hitbox since 1.9), and that´s why you can see through him. But there´s still a block there. It´s just a rather weird block. Just wanted to add that.
Can you give an example of a 0 tick pulse monostable for MCPE? Or what exactly did you test in MCPE that made you conclude that there are 0 tick pulses? Because the update system is as far as I can tell very much different from the PC version and I didn´t find any 0 tick technology that works in MCPE.
Edit: I found something that could be considered to be a 0 tick pulse. Ignore this.
A similar bug is also, that arrows lose their punch enchantment effect when being reloaded (
MC-59626). Both of these bugs occur, because the nbt structure of arrows is incomplete. Each of these bugs should be easy to fix, by implementing new nbt tags to the arrow, which could be done by just adding 1 or 2 lines of code to the functions which write and read the nbt data of the arrow.If this bug report (
MC-108695) is considered to be a dupe of (MC-108054), then I will heavily edit that bug report (MC-108054), because there are the following differences between the two bugs:1. Since 16w41a it´s not enough to move and reload the observers to produce the bug. You need to update them first, otherwise the bug doesn´t occur.
2. /setblock commands work fine in 16w41a
3. Since 16w41a observers now don´t always rotate towards +z anymore, but they also rotate towards other directions,
Basically I will have to rewrite the entire
MC-108054bug report, and I thought it would be more logical to just submit a new bug report for this. But I will just copy paste what I´ve written here intoMC-108054if you want.Observers do power blocks strongly. They just don´t send enough block updates. So if you use an observer to power something through a block, you´re creating BUDs.
So the actual bug is this one:
https://bugs.mojang.com/browse/MC-108696
"Is this still in Minecraft 1.11?"
Yes.
Minecraft 1.11 should be added to the affected versions of this report.
"Is this a problem?"
No.
(at least if you ask me)
Here´s a less obfuscated version of the relevant part of the code. It´s the beginning of the moveEntity() method in the Entity class in 1.12 MCP, except that I renamed some variables.
and then there´s the rest of the moveEntity method.
While I don´t like this behavior, it looks intentional, so I don´t think this bug report will go very far.