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
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
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.
Exact, sorry for duplicate !
Yes I understood that technicaly it's the same system, that's why it's the same errors messages 😉
But maybe the bug is here: a book is NOT the same think that the chat.
I remember some week ago when tomas (Minecraft PE developper) say that in Minecraft PE the item frame is a block, not an entity: because it's not normal that an entity is displayed like a block.
Here it's the same think, the bug is that a book is not a chat, so it's not normal that chat limitation limit book command. (And honestly I don't understand why there are this 100 char limitation for chat...). The server know the book, it know the player, Minecraft don't need client send the command to server through the chat system, it's a design problem that need a solution, it's a bug to fix.
And why the same command work in a command block and not in a book ? It's not consistent, technicaly it's possible. Maybe the solution is that book should work like a command block and not like the chat.
I already receive tens emails of users that have this problem (and I'm sure many other also have this problem without say it), so there are a real problem here that impact many peoples.
And if really your are right, if it's is a desire of mojang, if it's not the lazyness to solve the bug, so it's not normal to display a random error message:
"Invalid json" ??? what ? the json is valid !!!
"Data tag parsing failed: Unbalanced brackets" ??? There is no error with brackets !
A normal way should be to refuse the /give command because of the command too long (here the /give work, but the book is corrupted), or to display an error message like "Command too long", but any way, there are a bug with the book and run_command and I hope developers will not close this bug report without to solve a problem that affect so many users (and spam my mail box with messages like "your generator is bugged, there are bracket error" or "your generator create invalid json" :-/).
Skylinerw : In MC-30955 Searge spoke about the tellraw command, tellraw is a chat command, so that make a sense that a chat command have chat limitation. But here I speak about books, there is no reason to limit book feature by chat limitation. And if it's a chat system limitation like you say, that means it's a bug in Minecraft and mojang should solve it, that don't means it work as intented 😉
"Work as intented" means it's a feature that developper want, that don't means they are too lazy to solve it 😉
About the trigger solution, yes it's a solution for tellraw command because most of time tellraw command is part of a command blocks system, but that make a non sense to need a command blocks system to be able to use a book.
We speak about the run_command, not the suggest_command. suggest_command display the command in chat, so it's normal to limit the size. But I don't understand why the lenght should be limited with run_command. The biggest problem is with book: there are the same problem: many users report to me the problem with my book generator: command run from a book are also limited, so it's very difficult to make commands book with this limitation.
Confirmed for 16w06a
Still present in 15w46a, the bug is not resolved
Yes it's mention, if I make a search on the page on the keyword "flower", I find:
"flower.png" => the old texture, already fix for horizontal center only, and no mention about the flower in the post, I think an image is not a bug report, no ? 😉
"The pixelation is intended, however the fact that the flower displays off-center is not." ==> the pixelisation problem is not a bug, I agree, my report is not about the pixelisation, it's about an alignment problem. This comment report the center problem, but as I already said, jeb as already fix this bug... but only horizontaly, so for him this aligment problem is solved.
"The Fixed Flower Pattern." ==> Yes, it was fix horizontaly only, there is always the vertical problem now, and I'm sure jeb don't know this very easy to solve problem (only 1px difference) :-S
So no, I really don't think it's not the same bug, the MC-86135 only use the flower as an example of the pixelisation problem (and I agree, the pixelisation difference is very visible on the flower), but it don't speak anywhere about the texture alignment problem.
I hope you will understand my point of view 🙂
To be honest, I don't want to insert the bug in my online shield generator, so for the moment my shield preview is false, as you can see on the example here: http://minecraft.tools/en/shield.php?color_id_0=0&shape_id_1=13&color_id_1=4&shape_id_2=32&color_id_2=15&shape_id_3=0&color_id_3=0&shape_id_4=0&color_id_4=0&shape_id_5=0&color_id_5=0&shape_id_6=0&color_id_6=0
So what is the solution? I realy need jeb know about this bug, it's so easy to solve 😞
Hello Sonic,
It's not the same bug: MC-86135 explain the problem about the resolution difference between banner and shield.
Here I report a problem with a pattern position.
I speak about the banner only to confirm that the pattern should be centered, so it's a bug, not a feature. I know it's not the same resolution, not the same image, but it's not the problem here.
I agree that MC-86135 post some flower pattern image as example, but:
1 - the report dont explain the problem with the flower pattern position
2 - the flower picture are from the first snapshot with shield, the pattern have been modified in the next version (horizontaly centered, but not verticaly)
So, for me, it's a very different bug report.
Confirmed for 17w18a
I upvote this bug report because it's very annoying.
A workaround is to double escape the \n :
The following example work as intented: