The outer layer of your skin IS completely black. You need to have transparent pixels in those spots. Black does not get hidden.
The way I see it, the signs should all have text colors matching that of the item texture. Additionally, I would like to see the option to either recolor sign colors within the GUI, or have some kind of file in a resource pack to determine the sign text colors per sign-type.
If I may ask, why is this marked as "won't fix"?
What is making you guys not want to fix it?
I have stated the fix. It's really simple. I understand performance may be a concern, but you only draw one screen at a time, and for it to fetch a single string every tick (as opposed to the current way of fetching the string upon opening the GUI, and only that one time) is not going to make any more impact than it does fetching a list of items every tick.
Like Marcono1234 said, no NBT tag is used, so the server can't save it to the world. And I haven't tested multiplayer, so maybe some one can test multiplayer and see if others can see a "just sheared" snow golem to test for synchronization.
This will indicate if it is just client side, or if the data just is lost.
That's what the object variables are already doing.
I'd like to mention that the solution to this is actually simple.
The reason why it doesn't "update" is because the constructor of the GUI only saves the current name as a string variable. If the entity/tile entity instance were stored instead, then a simple getCustomName call in the draw method would fix it. I guess this was a performance concern. But it isn't going to make a huge impact anyhow. It's only allocating a reference in memory, not a whole new object.
@Kumasasa
Could you maybe change the post to say:
"Steps to reproduce are in the video, but also below".
I can't edit anything on mobile.
@dodo comododo
It's in the video. Hence why I wrote "steps to reproduce are in the video".
@Kumasasa
Thanks for adding it to the ticket.
Works as intended. This is a new mechanic where the fishing bobber becomes fully attached to the mob. If it is within the hitbox of the mob, it attaches.
/title @a title {"text":"Chapter I", "bold":"true"} works.
You forgot to quote "true"
This is still the case, even in 15w34a. Over one year. Wow.
There is additional details to mine. Can we change mine to just the added part then?
Confirmed even for 15w33b
You do not need to put quotes in the JSON, Mojang set it to lenient, which means keys don't require quotes. I found the solution as per your last advice, you do need all 3 (author, title, and pages) for the book to work.
So the following,
/give @p written_book 1 0 {HideFlags:32,title:"Book",author:"Author",pages:["{text:\"Hi\"}"]}
will work.
Moderators, feel free to close this. I apologize for this. It is true though, that the JSON generator no longer works, however. So Mojang must have changed their book parser without mention in the changelog.
This was Mojang's workaround to hacked inventories spawning command blocks with /op in them.
So technically, this is "works as intended". But really, who are we kidding. Mojang could simply disallow the /op command from command blocks, and even just clear the NBT of all spawned in items from creative menu. Rework the packet system a bit to create a server-side of the creative menu, and only allow items to be added/used from the server, just like it is in survival. No more functioning inventory hacks.
Why are the numbers inconsistent?
Squids are immune to it on land for sure, I just tested.
Everyone keeps saying this is a feature. But the twitchy movement leads me to believe this is a bug.
Either the AI needs to be tweaked to make this "attack" more immersive, or it's a bug needs to be fixed.
I don't mind the Ender Dragon stopping in the middle to do extra attacks, but it sits IN the portal, rather than fly above it, or sit near it. It just looks awful.
This is because blocks need an update. When they are generated, they don't update on their own. Much like "primed falling sand" needs a block update before it falls.
This is not a bug. This is a way to prevent the client from freezing by scheduling block updates for every generated block in a chunk.
Did you even attempt to replicate it? I just tried it conditional and not, it still behaves the same. This is not invalid.