Tronics

Fixed in 19w46a: it's now a neutral gray background (1pixel gray texture).

Confirmed for 17w18a

I upvote this bug report because it's very annoying.

A workaround is to double escape the \n :

\\n

The following example work as intented:

/give @p written_book 1 0 {pages:["{\"text\":\"My\\nBook\"}"],title:"My Book",author:Me}

Ok, so should I open a bug report because it's possible to add custom effect to the empty potion ?
empty means invalid, the pink color means invalid, it's not normal that people can add effects to an uncraftable potion don't you agree ?

There are a problem with this potion.
If I'm right, the color should affect this potion. If you right, it should not be possible to add custom effect to this potion. But it's not normal to allow player to add custom effect but not apply color, don't you agree ?

Ok, so if I understand you, the water potion is a potion with water and nothing else (because it is its name), that's why the color is blue... (the same logic)

Also that why it's not possible to add any others custom effects to the water potion, because it's water, not custom...
Oops, no, it's possible the customize the water potion, and the color can change.

The better solution should be to wait for an official answer from Mojang.... but it will be never possible because the bug report is now closed 😞

Hello FVbico, I think there is a misunderstood.

empty is not the potion name, it's the potion ID. It's like if you say that the ID 478 means invalid.

The potion name is "Not Craftable potion", that means the potion is not craftable, and this is more sense: You can't have an empty potion if you create a potion with random ingredient: the potion is not empty, but it is not craftable.

And I think you will agree with me that "not craftable" don't means not valid, that means you can't craft them with the crafting table, but only with commands, it's the bug I report here.

"not valid" should means there are an error, it's not an error to have custom effect for a potion, it's a customize 😉 Maybe mojang don't want player can make a custom potion with the not craftable potion (why ?), but I think it's more probably a bug, don't you agree ?

Edit: And yes 1.11 is still affected

This report can be related to MC-107192, but not the same: MC-107192 say the Potion tag is needed but don't speak about effect color, MC-109917 report say that the color is not correct, don't say anything about the Potion tag.

With multiple custom effects, this bugs occured when all effect have showparticles set to "0b".
If some effect have showparticles to 1b and others to 0b, the color mixer will ignore the color from the effect with showparticles to 0b (I don't know if it's intented or no).
Example:

/give @p minecraft:potion 1 0 {Potion:"minecraft:water",CustomPotionEffects:[{Id:6,ShowParticles:1b},{Id:8,ShowParticles:0b}]}

EffectID 6: Red

EffectID 8: Green
The result will be a Red potion, not yellow because Id 8 (green) is ignored

Still in 1.11-pre1 😞

"This is because the arrow and ActiveEffects tag doesn't save the CustomPotionColor tag, and the effect cloud doesn't write it to Color."
Seams that the CustomName and Lore tag are not store either, there are lost when pickup the custom entity arrow.

Confirmed for 16w44a

Still present in 16w40a

Confirmed for 16w38a

@unknown In my opinion the better solution is to apply the transparency detector only on 32x64px skin, and disable it on new 64x64px skins.
This don't break backward compatibility and that solve the problem on 64x64 new skin format (the original reported bug).

In all case, I think breaking thousands skins actually in use by player is a worst solution that have a bug only on new skin. There are thunsands of old skins (without transparency) on skins websites, and players continue today to use theses old skins :S

MCgaming4K Exact, that why I create the (duplicate) MC-98647. You right, it's important that Mojang view all impact of the bug before solving it.

@Searge Thank you for listen and your answer.
I agree the best solution is a future rewrite of the system.

But for now, what do you think about a more understandable error message (for example, when chat system receive a too long command, display the error message "command too long" and refuse to run the command ? I think (I hope) it can be more simple to implement ?

@FVbico: Thank for your understanding and for the corrections.

Skylinerw

"you're going to use the text component incorrectly"
==> User don't "use text component", they use a book 😉 How can a lambda user can know that internaly Minecraft use the text component ?

"You are trying to make the player run a command longer than they are allowed to run it"
==> How a user can know it is not allowed the long command ? No error message, the /give command work with no problem, so there are a bug you agree ^^
When you try a "/time set -5", an error message say "The number you have entered (-5) is too small, it must be at least 0" ==> that error message is normal, Minecraft refuse number < 0 and say it, it don't crash with an error like "overflow integer value" or sometime else.

"It's not an issue with books, that's simply how the chat works"
==> We agree, I'm fine, so you agree that it's not normal that a bug with chat impact books 🙂 My bug report is about book, not chat 😉 It's not the user problem to know how minecraft work.

"The /trigger command was introduced to bypass the issue while still allowing OP-only commands"
==> I'm so happy, you understand me !!! So you agree that /trigger is not a solution to bypass an error message. This bug report have nothing to do with op or no-op permission, it's about the display of false error message.

"Exceeding the chat limit is a very common mistake people make when using the text component"
==> That's why the text stop to display when user type the command 😉 Minecraft don't allow user to type the command then crash while execution ^^
So we need the same logic with book: an error while /give commande for example.

"There are plenty of other tickets where a lot people do not understand how something works and assume it's a bug"
==> And omderator don't understand that it's NORMAL that user don't need to understand how Minecraft work ? Minecraft have a bug, it's Minecraft to adapt himself to player, not player to read the source code to understand how use it 😉 But I understand now that moderator here don't understand the difference between a user and a developer, I will stop saying to my user to report bug here, it's impossible, reddit, twitter and email will be more usefull.

"there is a lack of understanding of the game's mechanics"
==> *game internal coding, see my previous message for answer

"something not a lot of people fully understand"
==> user that report problem with malformatted command, ok it's not acceptable, but here the command is valid, the command don't create error, but Minecraft corrupt the command when executing... it's not the user error, it's Minecraft which cut the command, not the user.

"To forcefully bypass OP"
==> I don't understand this part of your message, I never speak about op, the problem is the same for everybody, I don't want to force OP. I'm already OP, I don't need /trigger.

"Causing chat to have a maximum of 32767 characters would only encourage spam"
==> So don't use chat system with book 😉 only can can create book with run_command, so there are no risk of spam... It's not a duty to use chat system for book, and because here that make too many problem, maybe mojang should modify how book work 😉 Or display an error message when /give, or etc...

"/trigger is what you are supposed use, as stated many times"
==> as YOU say, mojang NEVER say that about book, because mojang don't know this bug, because moderator refuse to accept it.

"I also highly recommend you read my other comment and follow the instructions there"
==> You don't need to explain to me the cause of this bug, I already know, but like i say many time it's not my bug, I don't have problem with this bug, my problem is that I receive hundred of email about user that have this bug, user reporting a bug on my book generator, but it's a minecraft bug, not a bug with my generator. So explain the why and the workaround to the millions of Minecraft player... or accept to reopen this bug report... because it's not normal when a player need to learn how work a software internaly to use it...

I really don't understand this debate here, we don't speak about if Mojang should solve this bug or not, but if Mojang can know this bug or no... And why don't let Mojang decide ? I will never understand moderators here...

You never mentioned MC-70317, it's only an example to try to explain to you the difference between a bug and a feature. But you don't understand 😞 But I agree it's a good idea to let it be open, but it's not the purpose here.

I see mojira moderator don't understand the difference between a user and a developper: an error message is not a log entry, if developper want this kind of debug error message to understand the error, ok why not, but here it's a USER message error, a message that say the command is incorrect... It's not the user problem to understand how Minecraft work internaly, the most of user don't know how work minecraft, don't know how work a software, and it's normal, and when a software (here a game) say "invalid json" it's not "normal" when there are not error in json.

I will try another example, maybe you will understand the difference: Imagine if your car auto activate the parking brake when your speed is too high: it's normal, you can have a speed too high, it's not lawful, and maybe it's unsafe for your motor to run at full speed. But it's not the user problem: The user want have a speed, the car MUST NOT auto-brake, it's too dangerous. There are many work around too avoid this: reduce the throttle for high speed, remove the speed limit, add an warning led for motor temperature, etc... but don't automaticaly brake.
It's the same problem here. Mojang can forbid the creation of long command (with an error when user create the command) (same a lock a throttle), display a more descriptive error message (like the warning led about motor temperature), remove the limitation (why this limitation ? maybe it can be a solution), but never corrupt (by cutting) the command (like a care must not autobrake).

I will try another example to explain why you can't close this bug for duplicate with MC-30955: a book is not a tellraw command:
Imagine a user report a problem to his car builder, because the electric glass are too slow. The manufacturer close to report because it's work as intented: high speed glass can be dangerous, and it's a limitation from electric motors.
Some time later, another user report that wiper are too slow, and when there are an heavy rain it's dangerous. Moderator close the report because of "duplicate" because it's the same motor, and manufacturer say it's a motors limitation ??? It's not because internaly it's the same component that the bug is the same.

You can explain me 100 time why this bug occur because of internal limitation, ok I understand the "why", but no it's not normal, and user try again and again to solve his command, replace the double-quote, add/remove bracket, etc..., they don't understand the error message is FALSE.

But I understand you will never reopen the bug, it's not your problem that there are hundred of user voting for this bug, you (moderators) refuse that mojang can decide is yes or no it's a bug and if they want solve it or no...
So I will say to my user to stop vote for this bug if they want a solution, and stop reporting others bugs here, moderator seams to only accept there own (trivial) bugs report, I will say to them to send emails/twitter/reddit message to developers, because that seams to be the only solution to report bug. I don't want to lost more time with mojira, It's not my bug, it's a bug from my users. It's a sad news for community, it's a sad news for the mojang developper mailbox, but I don't see any others solutions to report this bug 😞

Thank you for answers and "explanations".

@FVbico : So you are trying to say to me that the MC-70317 (who ask to add the suggest_command to book) is not a feature request (else you should close it too), but ask that minecraft stop corrupting book is a feature request ???
I don't ask Minecraft change error message, I ask Minecraft stop corrupting book, there are many solution for that, some example:

• Refuse to create a book when run_command are longer than 100 chars

• Display a message error when executing the commmand that say the command is too long (and not saying that the command is corrupted, because it's Minecraft that corrupt the command)

• Allow more than 10 chars in run_command for book (because use trigger for book have no sense, we don'g speak about tellraw here: a book is an item, tellraw is a command)

• Stop using the chat system and his limitation for book

A don't ask any feature, I ask that Minecraft stop displaying a message error that is not true. The message error is for user, not for the system, so please stop saying it's normal: it's not normal, your explanation only explain why, internaly, Minecraft generate theses error. I understand why is the cause of error, but it's not normal for a user to have a message "invalid json" when your json is too long. It's not because you can explain the reason of the error message that means it's normal, it's not normal.

I ask here to stop closing this bug report because this bug is REALLY different that the bug about tellraw. I only ask to you to let mojang decide if they need to solve it or not, because for the moment it's impossible to report this bug, and mojang don't know him.
The only answer from Mojang (from Searge) is about a command (tellraw), and his answer is to use another command as a work arround (that make a sense, so I can understand his choise). It's true that if Searge solved the tellraw bug, the book bug should be solve too (because the source probleme is the same, but because he refuse to solve the tellraw error we have another bug now: The same problem (minecraft cut command) have many impact (many bug), it's not because it's the same component that it's the same bug, and this bug report is the proof, the same probleme can:

• Cut a text

• Generate "Invalid json" error with tellraw

• Generate "Unbalanced brackets" error

• Corrupt book
  etc.
  Searge answer is only for one of this problem, and is workaround have sense only for tellraw (a command workaround for a command problem). His workaround solve the limitation problem for command only, his solution don't solve the problem with book (other bug report don't say about book) and don't solve the bad error message problem. So we need report others impact to him, I think he don't understand the real impact. If searge (or jeb or any other Minecraft developper) say they don't want solve it, ok, but for the moment the problem is that mojira moderator refuse we can report this bug, so Mojang developper don"t know this bug exist, and MANY user continue to report this probleme (50 votes for MC-70317 and 22 here), and I don't speak about hundred email a receive about this. I think mojang don't know the real impact of this bug, that why I create a more complete bug report, explaning all related problem for book.

I only ask you accept this bug report, you accept that user can vote for it, and so you accept that mojang can view it and, maybe a day, solve it.

@FVbico It's not a feature request because the error is due to Minecraft. Minecraft say "invalid json", but json is valid... so it's a bug if the message error is not correct. This bug report explain how (internaly) Minecraft cause this bug and how it is possible to reproduce it (to help developper to solve it), but the bug is that Minecraft corrupt the books, and display random error messages.
So this bug report should be reopen