Confusing error message when using run_command

@unknown again, how run_command works is it executes if from the chat (intended), and because it can't fit the entire message due to the lenght, it cuts the too big part off (intended, go and try and paste a super long message in the chat, you'll see it gets stopped at one point), if a command get's cut off like this, it results in invalid json, a new error message is a feature request

@@unknown The "invalid JSON" error is correct. The error does not concern the book, it concerns the command you are typing into the chat by using the book. At that point the book is unrelated. The message is not random: it is telling you that the command you're running is malformed because it is at the time of running it. The error has nothing to do with the book and only to do with you, as the player, running a command that exceeds the maximum character length for chat input.

For example, copy the following command and run the command yourself in the chat, not in a command block or via a book:

/tellraw @a {"text":"Minecraft Minecraft Minecraft Minecraft Minecraft Minecraft Minecraft Minecraft Minecraft Minecraft","color":"yellow"}"}}

You'll see it is first trimmed, but enter it into the chat anyway. You'll receive the JSON error because the JSON is malformed due to having been trimmed. This has nothing to do with the book, only to do with the player's chat limitations. Using a command block to run the command will work fine because the command block does not have a 100-character limit and, in the end, is not related.

@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.

run_command is run_command, if it's in tellraw, a book or a sign doesn't matter at all, the book is not corrupt, never has been, the tags are still the same as what you provided, the command is simply too long to be player executed, the current message is intended, and any change to this would be a feature request and not a bug, go to reddit with this, because how the run_command in all of these objects function as of now, is the intended way.

also, I never mentioned MC-70317, and that one is still open, and unsure if intended, mojang will decide on that one.

If you still don't understand what I'm trying to say, read @unknown's comment before replying again

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".

@@unknown There is nothing unexpected happening if you're going to use the text component incorrectly. You are trying to make the player run a command longer than they are allowed to run it: therefore, the command is trimmed, and the player running that command will receive whatever relevant error would occur due to trimming the command. It's not an issue with books, that's simply how the chat works. The /trigger command was introduced to bypass the issue while still allowing OP-only commands to be used to differentiate between players with elevated permissions (which is a very important and useful distinction).

Exceeding the chat limit is a very common mistake people make when using the text component, which is why there is attention brought to tickets like this and does not make the issue any more valid. There are plenty of other tickets where a lot people do not understand how something works and assume it's a bug, but that doesn't make the report any more valid. It just means there is a lack of understanding of the game's mechanics. For example, datatype declaration for NBT data is something not a lot of people fully understand, which results in a lot of invalid bug reports concerning it. There isn't a bug happening, but instead people do not understand how it works.

To forcefully bypass OP requirement would lessen the usefulness, as the important distinction of OP'd players is lost (and then /trigger itself essentially becomes useless). Even increasing the character limit for chat wouldn't solve anything because there would still be a limit and people would still make reports when they unwittingly exceed the new limit. Causing chat to have a maximum of 32767 characters would only encourage spam. Preventing a /tellraw command or a book from parsing its text component due to the length of a command would not solve anything because people would still make new tickets and get them closed for not understanding the mechanics. This is simply a matter of people not understanding how something works and thinking it's a bug when it isn't.

/trigger is what you are supposed use, as stated many times. You should be explaining this to people instead of encouraging them to spam the developers (who will simply tell them to take it to the bug tracker).

I also highly recommend you read my other comment and follow the instructions there, which clearly shows that there are no abnormal errors occurring.

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...

Fine, reopening, please change the report to make the issue more clear in the description (confusing error message)

@@unknown The mechanics are observable in-game and you do not need to know what the game is internally doing to determine what's happening. If your generator does not abide by mechanics nor teaches users the mechanics, then there will naturally be confusion among the users. You should correct or update your generator to adhere to what the game currently does if you have not done so already (which will relieve you of support emails you receive as well as help your users).

As far as I can tell, your true issue is not to do with books or the /tellraw command, but instead the chat limitation in relation to using the run_command function of the text component. You are looking for an error to be implemented that warns the user that their input was trimmed, which is understandable, but please do understand that it is not specific to books as you are so strongly defending. It's for the text component. And if your strict definition of what Mojang deems as working as intended does not apply (and it's here I should mention that the term "tellraw" is commonly used in place of "text component", which is unfortunately misleading but still common), then it simply is a duplicate of MC-30955.

Otherwise it's on par with a feature request. Considering that it's a request concerning a non-present error message, I am unsure how moderators are to deal with reports like that, especially since MC-30955 was closed without implementing a new error message (and please, look past that the context of that report is "/tellraw" and instead look at the resolution, comment, and lack of implementation changes). Regardless, I would highly recommend refocusing the report on "text component", "run_command", and "lack of overflow warning", rather than "books are not tellraw" or anything specifically concerning books, which are really not the underlying issue here. Any other sort of implementation is a feature request (increasing character limit, causing commands run by the text component to be at an elevated level like command blocks are (which is again a step backwards), etc).

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

The commands in written books are submitted through the chat system. They are not handled server-side and are executed with the permissions of the player who is clicking the text component. The chat line is limited in length.

This is the reason the /trigger system was introduced in 1.8 to have an alternative solution to the problem.

Changing this would be a feature request, it is not a bug. I'll consider it for the future, but won't make any promises right now.

@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 ?

MOJANG THIS ISN'T RESOLVED!!!!
please resolve it REALLY!!!!!!!! i'm so Angry

(For 1.10)

and if you can add unlimited command blocks space

Resolution: Works As Intended

Guys, for everybody that is having problems with this bug I found a work around to it...

This bug happens when you run a command via tellraw by making the player click a text...

Just simple put as as the command: /setblock x y z redstone_block

Then put a command block on these coordinates: x y-1 z and put your long command block line there...

In that way the redstone block will power the command block that will have no limits... that's a cool workaround, I hope it helped!

I want this to change!

A bit, in java, can have 256 numbers. No more.

If command characters exeeds 256, the 257th characters and after aren't supported

The bug are also for the flat world, when we change the line of layers. Then the game crash.

I'm french, cetrains translates don't exactly

Please Fix this bug. I want it to allow more then 256 numbers!

Please Fix this bug. I want it to allow more then 256 numbers!