Pete Frisky
- downunderit
- downunderit
- Australia/Brisbane
- Yes
- No
MC-17876
Normal
Low![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
The simple horizontal piston array when powered shows the inconsistent redstone signal at work. This may be the result of premature bud affect that was not present before resent snapshots.
Simple horizontal piston array from the top
2013-06-26_09.31.56.png
Player/mob heads are offset on baby zombies and on villager baby zombies the head is still floating above mob. Heads on normal baby zombies look close to align but when zombie looks down face clips through head.
Exactly the same issue as bug #
MC-2664except hit boxes are good. So it was marked as fixed but not visually.Only MC version floating head was fixed is 14w33c
Player using book to 'cast' click on a score command targeting themselves does not work on half slabs. More correctly updating score with book fails between elevation of y@.50-y@.56 (y@=full number in the y axis).
Have tested this bug as far back as the chain and repeat command blocks were added and always fails.Below are commands to replicate:
Book:/give @p written_book 1 0 {pages:["[\"\",{\"text\":\"Bug testing \",\"color\":\"dark_blue\",\"bold\":true},{\"text\":\"\n\",\"color\":\"none\",\"bold\":false},{\"text\":\"Test \\\"Click Cast\\\" below on half slabs. \",\"color\":\"dark_green\"},{\"text\":\"\n\",\"color\":\"none\"},{\"text\":\"Click Cast\",\"color\":\"light_purple\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/scoreboard players set @p[score_mana_min=2,r=0] CAST 1\"},\"hoverEvent\":{\"action\":\"show_text\",\"value\":{\"text\":\"\",\"extra\":[{\"text\":\"expect text \\\"Cast test successful.\\\"\",\"color\":\"red\"}]}}}]"],title:Halfslab Book Bug Test,author:RCvie}Objectives:
/scoreboard objectives add mana dummy /scoreboard objectives add CAST dummyMana score:
/scoreboard players set @p mana 100 /scoreboard objectives setdisplay sidebar manaCommand Block chain on repeat:
/execute @a[score_mana_min=2] ~ ~ ~ /scoreboard players remove @p[score_CAST_min=1,r=0] mana 2 /execute @a[score_CAST_min=1] ~ ~ ~ /say @p Cast test successful. /scoreboard players set @a[score_CAST_min=1] CAST 0
Evocation_illager and Vindication_illager do not display custom items in head slot or custom held items when attacking.
Have tested with 100% drop rate and custom items drop on mob death but are not visable on living mob.
Vindicator will display iron axe when attacking even if weapon is replaced.Tested other armor slots but seeing as they did not drop I'll leave that for suggestions on Reddit.
Affects snapshot 16w39a
Previously an unread written_book had "resolved:0b" parameter that was searchable with commands, now it no longer shows with a data check, even if the give command stated it.
Resolved:1b is searchable with command after book is resolved though.```
{"text":"Page1, "}
give @p minecraft:written_book[minecraft:written_book_content={pages:['[,{"selector":"@s","color":"red"}]'],title:'Anything',author:'Blank',generation:2,resolved:0b}]
```While holding unopened book using, /data get, you'll be unable to find "resolved:0b"
/data get entity @p SelectedItem
Open the book, repeat the data get command and you'll see it now displays the "resolved:1b".
Another command to prove the point, just change the following {resolved:1b} to "0b" to see that before reading the same search is not possible using the new components system.
```
execute if entity @a[nbt=\{SelectedItem:{components:{"minecraft:written_book_content":{resolved:1b}}}}] run say toot
```
Previously an unread written_book had "resolved:0b" parameter that was searchable with commands, now it no longer shows with a data check, even if the give command stated it.
Resolved:1b is searchable with command after book is resolved though.
give @p minecraft:written_book[minecraft:written_book_content={pages:['[
{"text":"Page1, "},{"selector":"@s","color":"red"}]'],title:'Anything',author:'Blank',generation:2,resolved:0b}]
While holding unopened book using, /data get, you'll be unable to find "resolved:0b"
/data get entity @p SelectedItem
Open the book, repeat the data get command and you'll see it now displays the "resolved:1b".
Another command to prove the point, just change the following {resolved:1b} to "0b" to see that before reading the same search is not possible using the new components system.
execute if entity @a[nbt=\\{SelectedItem:{components:{"minecraft:written_book_content":{resolved:1b}}}}] run say toot
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
Thank you for your feedback, Pete Frisky. As the reporter of this bug, you can update the affected version(s) yourself, so please try updating this ticket from time to time.
Pete Frisky, you (as the reporter of the ticket) can update the affected version yourself
Pete Frisky, the issue you mentioned is MC-111328
@Talis I have had this same issue for awhile. Have seen other bug reports on this issue that have been tagged resolved with a response of "feed ocelots multiple fish to tame". Feeding a 64 stack of fish does not change this bug. I am now using the 1.4.6 update and the issue of not being able to tame a player spawned Ocelot in creative mode is still present in my main map. I have been able to create a new map and am able to tame an Ocelot under same conditions. Changing maps is not a resolution if the adventure map I'm making was to allow Ocelot taming.
I'll see about making a video if still needed. I've done more testing on this issue. Being in creative and spawning ocelots in a small enclosure seems to cause the major problem i have with taming ocelots. I've test on my old and new maps and found if an ocelot is running into a wall and then walks toward you as if ready to tame it will remain an ocelot. Best replicated in an enclosure with 7x7x2 walls. For some reason they need to run away a distance without getting stuck on a wall or fence before making the tame-able walk back to you. Simply by doing the same test in a 9x9x2 enclosure I was able to tame ocelots.
Can anybody else duplicate these results?
Have this issue too in single player, Snapshot 13w02b. As much as I'd like to control golem aggro it is too random. Sometimes I can walk past the golem fine but I have been killing zombies and zombie villagers and the golems starts attacking me and not the zombies. The agro is not reset even after i die, or exit map.
I understand normal blocks used as heads on baby zombies float at normal head height. But if player heads and mob heads are wearable masks then baby zombies should have these object render at correct height as the helmets do, I mean if Mojang doesn't mind.
This graphic glitch is just more common and noticeable with the new texture pack stitching but still exists prior to the 13w02b snapshot for me too.
I'd like to mention that the @p still does not work with "/scoreboard players reset @p" in 13w05a. As this bug is also reported here and report is marked as Fixed, could this be looked into again.
Yes Ray that is the same issue. The fact that it is not just about messed up graphics. I have a portcullis setup and where the second row of pistons should push up the head of the piston replaces its base and I don't get the full length of extension from both pistons. Still present in 13w05a.
Seeing as redstone and rails can be placed on top slabs and upside down stairs this is more a bug than an unimplemented feature.
Yes, as the other piston pushing piston bug, that resulted in the graphics glitch was fixed to an extent. In my 13w06a tests, a horizontal array of pistons powered from above will only activate every second piston. This kills any hidden stairways and my horizontal feed portcullis.
The simple horazontal piston test. 2 rows of pistons powers from above. Powering this setup in v1.4.7 and below will result in the second row of pistons being pushed out before extending themselves. The snapshots leading up to the 1.5 update including 13w09a still result in every second piston extending inconsistently. Adding extra sceenshots.
@Ray Kohler I know, not feeling like this is been seen. Trying to spread the word on the forums but getting no love. More people need to up vote this.
@jeb thanks for addressing this, I was worried it was hidden with so few votes. Now onto
MC-9460. It's a good start.A couple piston issues fixed and another won jumps up. Trouble with this one is it's not just a graphical glitch, they completely vanish from game.
I am getting this issue in the 1.5 pre-release as well. On single player creative. Sometimes the paintings com back on relog, other pre-existing paintings vanishing completely. Checked painting entities with MCedit and the ones I've tried spamming onto the wall were there while others I didn't touch have gone completely.
Still present in 1.5, baby zombies and baby villager zombies do not drop exp or burn in daylight. Have even tested with MCedit filters that were set to drop items 100% of the time and still no items or exp.
Using the 13w11a snapshot, placing of painting is possible for me now, have only tested on creative single player though.
It is likely Rebecca Banks thought it was fixed for the 1.5 release.
Testing in 13w19a all Stone variant slabs are able to be broken with an axe in Adventure mode, just normal axes not enchanted. Would this need a separate bug report?
Still present in the 13w24a snapshot.
I too can confirm this on a windows 7 machine. My on board time is correct. Was in a creative world.
Still present in snapshot 13w24b
Admin is going to say this too, try searching before you post a bug, this has been duplicated many times already and is known.
This issue duplicates
MC-17830and has been marked resolved on future update.@clement Desg I can't believe you made another bug report on this same issue after replying to this one. Not how the system works, search then up-vote an issue by clicking on the blue writing on the right hand side that says "Vote for this issue".
Still present in 13w15a
The armor display issue with less than 5 health has been fixed in 13w25a snapshot but the Max Health reset on death is still present thought it's more likely linked to this report now, MC-17876.
@Dominik, Yes I meant 13w25a.
Also just confirmed with the 1.6 pre-release you don't even have to log out to lose the extra health. I gave myself the Health boost effect x 4, healed up and then the health just vanished and I was left with 10 empty hearts. Was in survival mode and the character body shuddered like I was taking damage but with not hurt sound. And that left me with an empty health boost.
I've just tested with the long regen potion. Every time the Health Boost Effect hits a 30 second mark the additional health is removed.
Oh and the health now remains after login, as long as it's within that 30 second window.
@Kumasasa Thanks for the heads up that it is a separate issue now.
Yep still an issue in 1.6.1 Pre-release. No experience or other drops. Tested on natral zombie converted baby villager and edited baby zombies that were supposed to have a 100% drop rate, no drops at all.
Still an issue in 1.6.1 pre-release.
Pumpkins and player/mob heads still hover over baby zombies in 14w05b.
Also of note: when shooting arrows at the floating mob head the arrows bounce off the head.
@Noah you mean to say, It would be nice, if convenient, for the Mojang team could address this issue? It's inconvenient for me too but lets not sound like it's a demand. It would be nice if it was addressed is all.
On a side note the Pigman anger tag is broken much like the "Angry" wolf tag has been broken for a long time. Unless you damage one physically yourself the are not agro.
Still an issue in 14w11a
Can still confirm for 14w11b a spawned Pigman with a positive "anger" tag is not agro until attacked or if nearby Pigmen are attacked.
Have tested attacking Pigman, forcing agro, then spawning Pigmen with and without a positive anger tag. Pigmen spawned after initial attack will not attack player. Relogging will also remove agro even if anger tag still shows positive number.
Have only tested in single player world.
Ok I'm moved my support over here from the Pigman agro bug but I believe there have been previous wolf agro bug reports that were shut down previously with no interest shown. I guess that key point about the wolves looking angry and behaving angry was never fully investigated. If they fix this issue maybe an "angry" tag should be on all mobs.
@Roadsguy Blocks still float and hit box changed in the way that allows them to pass through 1 high holes but odd things happen graphically when you try shooting arrows at a floating head or block. Arrows look like they bounce off the floating head, appear in one location then disappear and reappear in another location along the arrows previous trajectory.
I am concerned that the Anger and Angry nbt tags are different as one is a true/false tag and the other involves a countdown in game ticks. Does that affect priority of these bugs because the wolf agro has been an issue for a while with no support?
Does the Pigman issue get more support if it raises the issue that the Zombie Pigmen can be exploited as you just have to log off and log back on again for them to lose their anger?
This still affects currents snapshot 14w30c
Unless of course this is being left as a feature for Halloween to see pumpkins floating above baby zombies? Every other day of the year it's just problematic to customize baby zombies, pigmen and villagers.
This issue was fixed and last working in the 14w33c snapshot, now broken slightly again in the 14w34d snapshot. Baby zombie villagers, player head hovers above again. Baby zombie, player head is slightly high just showing Zombie head/chin. PigZombie baby is same as normal zombie baby. Will add pics.
I found a good description of how the 'DisabledSlots' works and in 14w34d I am not having an issue with it.
This part is correct:
Flag Number Effect
1 disable removing all part, and placing/replacing Hand
2 disable removing Boots
4 disable removing Leggings
8 disable removing Chestplate
16 disable removing Helmet
However if you want to disable removing/replacing all slots you use flag '31'. /summon ArmorStand ~ ~ ~
{DisabledSlots:31}You add the flag numbers together to achieve the desired disabled effect.
#3=(1+2) would disable Hand and Boot slots. #24=(8+16) would disable Chestplate and Helmet.
Still broken in 1.8 pre-release. Any chance mod can put fixed version as 14w33c even if it is broken again for pre-release?
You were so close.
You do realize this was implemented to stop X-ray textures? You are looking at the back of a texture, it's supposed to be mirrored.
Still bugged in 1.8.1 pre4.
@Sonicwave The floating heads are not fixed for 1.8.2-pre1. Baby zombie villagers have a mounted head at 2 high level. Normal baby zombies mounted head sits slightly offset high, but is very noticeable if the baby zombie is looking down at you as the zombie face offsets through the mounted head. When looking up the mounted head becomes more offset upward. That is why the hit boxes are still 2 high. There is a picture of the 14w33c snapshot, the only time the baby heads where at correct level.
Still confirmed in 15w31c
You're going to need a bigger boat.
Still effects 15w35b, it's the first thing I check in snapshots. Test it with baby villagers zombies if you want to see the big issue.
Besides even with normal baby villagers it is still offset when the baby zombie looks down the zombie face clips through.
Done,
MC-87219Still an issue in 15w35b snapshot even if replace or keep arguments are used to fill skull block with the same skull.
Still an issue in snapshot 15w44b. Even with pumpkin on their heads.
Still affects 15w46a
Sorry FVbico I don't see how it could be intended, there are many texture UV mapping issues in the game that are more visible when higher detail resource packs are used. Fixing the texture UV mapping for the arrow doesn't make anything harder for the game.
I'm getting this too on signs and placed skulls as well as chests, but oddly only at certain viewing angles.
still affects 15w47a
Thank you Skylinerw for pointing out this is not a bug but a feature that Creeper NBT:fuse can not be tracked and expected to work like TNT NBT:fuse. Now the question is what NBT are we to track for Creeper fuse count down? Otherwise I guess we now have to suggest a real creeper fuse on Reddit and hope next year it gets added.
Ok bug closed as invalid but why is it linked to MC-55516?
This bug was in regard to head and held items not rendering, even on normal villagers custom head and held items render. This was not in reference to armor not rendering, I know normal armor slots are not on villagers.
Arrow texture still not correctly mirrored in snapshot 16w42a.
Still deep child villager zombie sounds 16w44a.
Texture still an issue in 16w44a.
Arrow texture still incorrectly mirrored in snapshot 16w50a
Still an issue in 17w13b.
Still issue in 1.12 pre-7
{resolved:#}It appears this issue also affecting command given books incorrectly displaying scoreboard and entity selector syntax if opened for first time in off-hand. Tag
also incorrectly triggers to 1 in offhand when clearly not resolved.
@Charlene You can also beat a chicken to death with the rod, or just use an xp farm of any sort but issue still remains that no mending while fishing defeats the purpose. I did enjoy killing chickens with a rod though while testing.
Can confirm issue. Surprised this has not been assigned or up voted as it will break all adventure maps that require any right click action in close proximity to a block.
And I thought I was doing something wrong. Good to know it's only a bug.
Question: is this the same bug that affects opening a book in the off-hand that ignores selectors?
This is still a problematic bug to going into 1.14 release. I understand that most hardened creators may not come across this issue working with functions or pasting everything into command blocks but some of us like to again select text in game larger than the visible text box.
Still an issue. Was hoping the new texture update would highlight it more, I guess not.
Up to current snapshot 19w14b
So this bug is back for 1.14 pre release 5. Do we Submit new bug report or reopen this one? Tested in creative and survival, normal arrows shot when relogging in will have particles emitted from them.
The previous update this worked on was 1.20.2
Sorry for my delayed correction to this bug report, {resolved:0b} is not in the normal generation of a written book. {resolved:1b} only generates after a book is read. However in the 1.20.2 version, when adding {resolved:0b} into custom nbt in the /give commands, the read book would replace the '0b' with the '1b' and be able to be identified in data get commands.
With custom NBT move to custom_data, {resolved:0b} can not be placed in a /give command and be detected as changed state because the normal {resolved:1b} is not custom_data and the placement of the {resolved:0b} in the original posts' command is not saved as part of the written_book components.