Frostyflyrap
- Frostyflytrap
- frostyflytrap
- Asia/Shanghai
- Yes
- No
MC-94264
![[Mojang] Rebecca](../../../data/avatars/users/18936.svg){kind=small}
Zombies (or other mobs) spawn with a 0% probability to spawn with the CanPickUpLoot activated. When I manually spawn zombies and scatter some items around the place, none of them pick the item up but a large amount of zombies should've picked at least one of the items in past versions. I summoned a zombie with a CanPickUpLoot tag on and they were able to pick the items up without any problems.
Is this a bug or an intended change?
Windows 8, Java 8
Zombies (or other mobs) spawn with a 0% probability to spawn with the CanPickUpLoot activated. When I manually spawn zombies and scatter some items around the place, none of them pick the item up but a large amount of zombies should've picked at least one of the items in past versions. I summoned a zombie with a CanPickUpLoot tag on and they were able to pick the items up without any problems.
Is this a bug or an intended change?(NOTE: this is a duplicate bug report, I made a mistake with the first one.)
Zombies (or other mobs) spawn with a 0% probability to spawn with the CanPickUpLoot activated. When I manually spawn zombies and scatter some items around the place, none of them pick the item up but a large amount of zombies should've picked at least one of the items in past versions. I summoned a zombie with a CanPickUpLoot tag on and they were able to pick the items up without any problems.Is this a bug or an intended change?
Chain command blocks that are set to conditional will not activate if the command block behind it succeeded to execute.
In the attachment, there's an impulse command block pointing at a chain command block that simply performs "/testfor @p". The block nest to it performs "/say true". I've activated the impulse command block and the comparator activated, but not the other chain command block that should've detected the block behind it despite it not pointing in its direction.
This used method to work in 15w35b, however that snapshot has been completely replaced replaced with 15w35e in the profile settings, hence this cannot be tested in that version at least for me.
If this feature was removed on purpose and seen as a bug, then please explain why. I think having a conditional chain command block branching from another is way better and direct than having to use comparators. Comparators even power a block and all the blocks adjacent to the block it's powering, so it can disrupt other command blocks. If there were some good reason why this feature was removed, please tell my why and how it was decided that it's not best for the mechanics.
Update: Here's an explanation of what I expected to happen:
https://youtu.be/k6kxuH9AY4U?t=24m29s
Still applies to version 1.12.2.
2019-02-07_01.08.27.png
Still in 1.15.2
Confirmed for 20w21a
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
Confirmed not fixed in 19w06a with the example provided by Frostyflyrap.
I am fully aware that chains activate the block they're facing towards, what I don't understand is why this actually worked in 15w35e and it does not work anymore. It doesn't make sense that this mechanic has been changed.
Huh that's strange then. But I did say 15w35b not 15w35e, I added a video where the thing works in the description. Shame though, I wish they'd kept it.
Well what do you know, turns out it actually still works in 16w03a. I guess this is resolved then?
Hmm, now I wonder how I can do what I've been wanting to do now that I know how this actually works. So I guess I still need comparators to do what I'm about to do.
Duplicate of
MC-83185.Still applies to version 1.9.4. Does anyone know if this is actually a bug or it's intended purpose?
Confirmed for release 1.10
This does look very strange indeed, but it could very well be a procedurally generated thing.
This is still active for the 19w06a snapshot
Source that this is intended?
Oh that's strange, even I made sure to search before I made this but for some reason, that bug report didn't show up in the results. Thanks for informing me about this.
This seems to be fixed in the latest snapshot.
Confirmed 1.14.4.
Isn't this a duplicate of
MC-147649?Why did the requirements to display a loom UI increase? It was working just fine on my computer in the last update.
EDIT: Interestingly, this wasn't an issue for me in 1.15 but it is now in 1.16.
In 20w45a
Confirmed 21w03a
Affects 21w03a
I see what you mean, but why does the tag "minecraft:fences" work as a proper tag then when it is also a block? Is this distinction due to how it's also a redstone component?