mojira.dev

aymeric pierre

Assigned

No issues.

Reported

MC-257171 Sculk sensor sipping sound comparator output wrong Duplicate MC-255702 Raid illager loose partial IA when spawning on upper slab platform Duplicate MC-107815 illagers respawn Works As Intended MC-50821 Cats and dogs teleporting into transparent-solid blocks (redstone_bloc, glowstone, TNT), causing them to suffocate Fixed MC-50701 Minecarts hitbox is wrong : they are more than 1 block tall Duplicate MC-50190 Hostile mobs don't spawn on nonsolid / transparent blocks as they should do Duplicate MC-46223 @a doesn't include dead players Fixed MC-31829 Can't load my previous saves in 13w38 : EXCEPTION_ACCESS_VIOLATION Duplicate MC-17254 Zombies stop targeting villagers when attacked by snow golems Duplicate

Comments

Still occurring in 1.8.1, observed in the nether with named zombie pigmen.

Ok. So it breaks every endermen / witch / wither skeleton / zombie pigmen farm. And it will not be fixed. Thx. ggwp

I agree, I just changed the title. The problem is not that redstone block, tnt or glowstone make entities to suffocate, the problem is that cat and dogs are able to teleport inside this blocks. Could a mod change the status of this bug pls ?

Yes, mod should definitively change the subject and title of this bug as it concerns all non-solid / transparent block like pressure plates, carpet, rails, tripwire and any dimension, not only end, as I explained here : [MC-50190]

edit : thx tails !

@unknown Not really a duplicate as the other bug only concerns end dimension and pressure plates. I'm afraid that mojang will only correct pressure plates issue and not the general non-solid block issues.

To be more precise, they do not dissapear when reloading, the entities are not saved when leaving the world (a simple way to check that is to open a world with mcedit after leaving while riding an entity : there is no more entity under you)

Strange indeed, not sure it's intended or not. But the first issue has been resolved, easy way to verify :

1. Create an objectives "dead" with death criteria
2. Add a command block on loop with "/testfor @a[score_dead_min=1]"
3. Kill you, the testfor will work before you respawn.

Yeah, fixing the issue by making player not reachable when he is dead was the easiest solution but the worst (they could add marker like "type", for example "status=alive")... anyway this is the bug tracker, not the suggestion tracker, I will try to reach jeb or dinnerbone through irc to talk about this and see if there is any way to solve this problem. Thx @unknown

@unknown I'm sorry but I still disagree with the fact that it works as intended. @a means "all players", not "all living player". And as @unknown mentioned, it breaks a ton of maps, without solving any other problem (why does this change would be made ? is there any other bug related to problems with @a pointing on dead player ?)

@unknown This is not a duplicate of MC-44521 as @unknown commented it. Simple way to reproduce the bug :

1. Create a random scoreboard objectives : /scoreboard objectives add random dummy - /scoreboard objectives setdisplay sidebar random
2. Setup a hopper clock runing on a commandblock with this command : /scoreboard players add @a random 1
3. You will see your score increasing
4. Kill you with the /kill command : your score doesn't increase anymore (the @a couldn't find you)

Not really fixed as you can't target dead player anymore (dead player are no longer count in the selector collection (@a, @e etc...))

I made some more experimentation and it seems, as Hartspoon commented, related to the target selectors. When you are dead, it seems that you are no longer a valid target for @a, and things like "/scoreboard player add @a randomobjectiv 1" add 1 only for the players alive.

Ok I see but in this case, the zombie doesn't go neutral at all. He just change his target from villager to golem. That wasn't the case before, and that wasn't mentioned in the changelog of the snapshot 13w18a.
I'll follow the issue MC-15112 and see if this behavior change when mojang will fix it.

I'm sorry but I don't see any relation between MC-15112 and this report. + the fact that what I described happened both in survival and creative (that's not the case for MC-15112), and doesn't concern skeleton at all.