Isaac To
- isaacto
- JIRAUSER704863
- Asia/Hong_Kong
- Yes
- No
MCPE-182420If we connect a hopper towards and out of a jukebox, they would be "activated" (i.e., locked) when the jukebox is playing, so no disc movement occurs. When the jukebox finishes playing, it unpowers, allowing the hoppers to give the jukebox a new disc. The whole process should take at most 2 ticks: the lower hopper takes away the disc, the upper hopper may wait for 0.1s, and then it should succeed in pushing a disc to the jukebox in the next tick.
But if the player leaves the area and unload the chunk when the disc is still playing, and leave the game, the jukebox no longer remembers that it is playing (this is marked to be "won't fix" in another bug). The jukebox thus unpower. But for some unknown reason (i.e., probably a bug), it unpowers for at least 0.4s, as can be seen in the experiment shown in the referenced video below. This makes it unnecessarily hard to build a jukebox multi-disc loop, requiring a multi-component circuit rather than a simple 4-tick repeater.
Ref:
If we connect a hopper towards and out of a jukebox, they would be "activated" (i.e., locked) when the jukebox is playing, so no disc movement occurs. When the jukebox finishes playing, it unpowers, allowing the hoppers to give the jukebox a new disc. The whole process should take at most 2 ticks: the lower hopper takes away the disc, the upper hopper may wait for 0.1s, and then it should succeed in pushing a disc to the jukebox in the next tick.
But if the player leaves the area and unload the chunk when the disc is still playing, and leave the game, the jukebox no longer remembers that it is playing (this is marked to be "won't fix" in another bug). The jukebox thus unpower. But for some unknown reason (i.e., probably a bug), it unpowers for at least 0.4s, as can be seen in the experiment shown in the referenced video below. This makes it unnecessarily hard to build a jukebox multi-disc loop, requiring a multi-component circuit rather than a simple 4-tick repeater.
Ref:
If we connect a hopper towards and out of a jukebox, they would be "activated" (i.e., locked) whe
nthe jukebox is playing, so no disc movement occurs. When the jukebox finishes playing, it unpowers, allowing the hoppers to give the jukebox a new disc. The whole process should take at most 2 ticks: the lower hopper takes away the disc, the upper hopper may wait for 0.1s, and then it should succeed in pushing a disc to the jukebox in the next tick.But if the player leaves the area and unload the chunk when the disc is still playing, and leave the game, the jukebox no longer remembers that it is playing (this is marked to be "won't fix" in another bug). The jukebox thus unpower. But for some unknown reason (i.e., probably a bug), it unpowers for at least 0.4s, as can be seen in the experiment shown in the referenced video below. This makes it unnecessarily hard to build a jukebox multi-disc loop, requiring a multi-component circuit rather than a simple 4-tick repeater.
Ref:
If we connect a hopper towards and another out of a jukebox, they would be "activated" (i.e., locked) while the jukebox is playing, so no disc movement occurs. When the jukebox finishes playing, it unpowers, allowing the hoppers to give the jukebox a new disc. The whole process should take at most 2 ticks: the lower hopper takes away the disc, the upper hopper may need to wait for 0.1s, and then it should succeed in pushing a disc to the jukebox in the next tick.
But if the player leaves the area and unload the chunk when the disc is still playing, and leave the game, the jukebox no longer remembers that it is playing (this is marked to be "won't fix" in another bug). The jukebox thus unpower. But for some unknown reason (i.e., probably a bug), it unpowers for at least 0.4s, as can be seen in the experiment shown in the referenced video below. This makes it unnecessarily hard to build a jukebox multi-disc loop, requiring a multi-component circuit rather than a simple 4-tick repeater.
Ref:
https://www.youtube.com/watch?v=OFQqkTPiXmA
Note: the quartz blocks in the video encloses one chunk space.
If we connect a hopper towards and another out of a jukebox, they would be "activated" (i.e., locked) while the jukebox is playing, so no disc movement occurs. When the jukebox finishes playing, it unpowers, allowing the hoppers to give the jukebox a new disc. The whole process should take at most 2 ticks: the lower hopper takes away the disc, the upper hopper may need to wait for 0.1s, and then it should succeed in pushing a disc to the jukebox in the next tick.
But if the player leaves the area and unload the chunk when the disc is still playing, and leave the game, the jukebox no longer remembers that it is playing (this is marked to be "won't fix" in another bug). The jukebox thus unpower. But for some unknown reason (i.e., probably a bug), it unpowers for at least 0.4s, as can be seen in the experiment shown in the referenced video below. This makes it unnecessarily hard to build a jukebox multi-disc loop, requiring a multi-component circuit rather than a simple 4-tick repeater.
Ref:
https://www.youtube.com/watch?v=OFQqkTPiXmA
Note: the quartz blocks in the video enclose
sone chunk space.
If we connect a hopper towards and another out of a jukebox, they would be "activated" (i.e., locked) while the jukebox is playing, so no disc movement occurs. When the jukebox finishes playing, it unpowers, allowing the hoppers to give the jukebox a new disc. The whole process should take at most 2 ticks: the lower hopper takes away the disc, the upper hopper may need to wait for 0.1s, and then it should succeed in pushing a disc to the jukebox in the next tick.
But if the player leaves the area and unload the chunk when the disc is still playing, and leave the game, the jukebox no longer remembers that it is playing (this is marked to be "won't fix" in another bug). The jukebox thus unpower. But for some unknown reason (i.e., probably a bug), it unpowers for at least 0.4s, as can be seen in the experiment shown in the referenced video below. This makes it unnecessarily hard to build a jukebox multi-disc loop, requiring a multi-component circuit rather than a simple 4-tick repeater.
Ref:
https://www.youtube.com/watch?v=OFQqkTPiXmA
Note: the quartz blocks in the video enclose one chunk
space.If we connect a hopper towards and another out of a jukebox, they would be "activated" (i.e., locked) while the jukebox is playing, so no disc movement occurs. When the jukebox finishes playing, it unpowers, allowing the hoppers to give the jukebox a new disc. The whole process should take at most 2 ticks: the lower hopper takes away the disc, the upper hopper may need to wait for 0.1s, and then it should succeed in pushing a disc to the jukebox in the next tick.
But if the player leaves the area and unload the chunk when the disc is still playing, and leave the game, the jukebox no longer remembers that it is playing (this is marked to be "won't fix" in another bug). The jukebox thus unpower. But for some unknown reason (i.e., probably a bug), it unpowers for at least 0.4s, as can be seen in the experiment shown in the referenced video below. This makes it unnecessarily hard to build a jukebox multi-disc loop, requiring a multi-component circuit rather than a simple 4-tick repeater.
Ref:
https://www.youtube.com/watch?v=OFQqkTPiXmA
Note: the quartz blocks in the video enclose exactly one chunk.
I have villagers in my artificial village (used as an iron golem farm) strangely despawned at least 3 times. At first I thought that there was some loopholes when spawn-proofing the village, that a zombie spawned, killed some villagers and is eventually killed by the iron golem. But later I concluded that it must be a bug because, for twice, I failed to repopulate the village completely (they won't breed any more), and at the end found an old villagers locked in an "impossible place": besides a trap, at a 1-wide 2-tall 7-long trench that has no entrance (because all around it is a wall leaving only a 1-tall space for me to see and kill the mobs inside the trap). Each time 3 or 4 villagers (of the 20 in that village) disappeared, and 1 of them is found in the trench. This does not happen often, my estimation is once a month when I play the world one or two hours every day and visited the village once or twice a day.
It happened on 1.17 (forgot the patch level, but not the most recent one), in a world originally created on 1.16. It is a single player world, only myself can access it. And I routinely exit the game with "Save and exit", not by closing the application window, although I might have accidentally hit the close button a few times.
I know the bit of info is hard to use (I write code too), but hopefully it gives the developers some ideas about what might be wrong (i.e., the mobs might not have simply gone, it could have been incorrectly positioned).
Another perhaps related observation is that there are usually unexpectedly large number of mobs around myself. That is, when I say "/kill @e", there are too many cats, dogs, sheeps, etc. I discover that because my hostile mob farm and my slime farm stop producing anything, although I counted all the mobs around myself and thought there there should still be ample of counts before the global mob count bound is hit (it isn't even half full). I don't know why, but in the most recent version this seems to be eased. Perhaps it is something to do with the render distance? Again, just mention that in case it is useful.
GoldenHelmet: Sure. I've created a zip file containing the game save directory. But it is 70MB so it can't be attached here. How should I give it to you?
Reply from [Mod] GoldenHelmet: you could upload the file to a file sharing site like google drive, one drive, mediafire, etc.
GoldenHelmet: One way I can show some info is by a video. See it here: https://youtu.be/VJ42Fw2e-6I
Replay from [Mod] GoldenHelmet: after looking at the video, I think the villagers could be walking over to the trap just like you did. If you're interested in testing, you could make a creative copy of the world and setup a tracer: a repeat command block executing on every tick with /execute @e[type = villager] ~~~ setblock ~ ~100 ~ glass. Then let the world run a long time.
GoldenHelmet: You missed the point.
(1) Even if what happened is what you said, it isn't reasonable: the villager has no ability to jump over the fence using the carpet as I did myself. The whole point of the design of the trap is to ensure that no villager can get anywhere dangerous. Of course, if the villager gets "teleported" to outside the village, that is another story.
(2) But that is not what actually observed. The villager is not at the place I finally stand, but in front of it. That is, it is in the trench between myself and the magma block (right above the chest if you can see it). At the end, to rescue him I have to break blocks so that I can enter the trench and push him out.
There should be absolutely no way that the villager could get to that trench. There is a row of upper slabs above the space he stand, so the trench actually has a height of 2.5. But to enter there he can only reach from the platform where I finally stand, which is 1 block higher than the trench. The space for vertical entry is only 1.5-tall. An adult villager has a height of 1.95, meaning that he cannot enter, just like I cannot enter. Can he be a villager who entered when he was a baby? No, he had trade experience. So the only thing I could imagine is a bug.
Edit: (1) I can reproduce villager lost in that world, by closing the windows without using "Save and Exit". Which is pretty much what the earlier comment of this bug says: across chunk border, mobs can get lost if you don't close the game properly. (2) Even if that happen, I cannot reproduce the problem that the villager get stuck in that trench.
I can imagine that this is actually a separate issue, perhaps it happened some time ago and I did not go down to the trench to see it when it is triggered, and when the villagers are actually lost I wait for it to breed but it stops when one bed is still "unowned". If I remove that bed and place it again I see green particles. At that point I know some villager is at a strange place, so I look for him and found the previously stuck villager. Just one possible explanation.
This is a parity bug.
In Java Minecraft, if the brewing stand is actively brewing portions, the portions will not be taken away from the brewing stand. This allows for easy automatic brewing, because you only need to check whether there are still ingredients waiting to be added, and if so disable the hopper.
In MCPE, this doesn't work. If you enable the hopper when the last input ingredient falls into the brewing stand, the bottles just started the last brewing will be taken away, leaving the last ingredient in the brewing stand and causing the whole setup to fail. You'll have to add a 22 seconds resettable signal extender to prevent it. Which is a big circuit.
I suspect that this is not a real bug, just unclear description of the requirements. I've just got the achievement in 1.19.41, playing Windows bedrock version. I suspect that you must do all the visiting without saving or exiting the game in between, so I inspected chunkbase to find the locations of all the 9 ocean biomes (warm, lukewarm, ocean, cold, frozen, and their deep variants except warm). Then I visit all of them in one go, the achievement shows up after a few moments. One thing I've noticed is that the last biome I've visited (finally triggering the achievement) is the deep ocean, although I've definitely been in that biome before because I've got the "let it go" achievement a few days ago. This probably confirms my theory that you must not save the game between visiting different biomes. Probably this is also why the progress bar doesn't change, because you can't be said to have "only one biome left" if you need to do it all over again once you save your game.
Note the piston on the left. If the signal generated by the jukebox lasts 3 redstone ticks (0.3s) or shorter, the 4-tick repeater should hide the signal gap, so there should be no time when the redstone torch is on. As a result, the piston should never have a chance to push. This is the expected outcome, and is indeed what'd happen if I do not logout the game and join it again (i.e., just move far away to unload the chunk and go back).
But if I relog as in the video, the piston pushed, indicating that the redstone torch emitted a signal before. This is deterministic: every time I do this the result is the same. If the rendering is fast enough I can see the piston pushed and retracted as the chunk is loaded.
When I discover the problem, I've connected the lower hopper to a chest, and I intended to use the signal to lock a hopper below the chest to prevent the discs in the chest to be drained. This circuit works perfectly, until I relog. Then a couple of discs are pulled out unexpectedly.
I agree that if the repeater forgets the amount of time that it should stay on after relog, it can be a problem. Agree to close the bug as duplicate for now, and I'll re-test it after 58151 is fixed (judging from the small number, probably won't be soon...).
I'm not sure how your modified design look like, but there is some randomness of the jukebox due to the two hoppers being unpowered at the same time. What will happen next may depend on which one goes first.