Section sign formatting codes no longer work
Using a MCedit filter made by SethBling, it was possible to give a color to text that's being said by command blocks (http://sethbling.com/downloads/mcedit-filters/colorcommandblocktext/) However, if you now power the command block, only the first word is colored.
Environment
Windows 7
Linked Issues
is duplicated by21
Created Issue:
Colored text isn't colored
Using a MCedit filter made by SethBling, it was possible to give a color to text that's being said by command blocks (http://sethbling.com/downloads/mcedit-filters/colorcommandblocktext/) However, if you now power the command block, only the first word is colored.
Environment
Windows 7
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
relates to
is duplicated by
is duplicated by
is duplicated by
is duplicated by
relates to
is duplicated by
relates to
Colored text isn't coloredSection sign formatting codes no longer work
is duplicated by
i'm assuming, then, when it's finally removed, written books that contain "§" won't read the same/ at all?
Probably. I don't know exactly what Mojang is planning to do.
for the record, the word "duplicate" does not apply here. it's simply a bug that would take more effort than its worth to fix.
Your personal ticket is a duplicate of (the same issue as) MC-31113, which is indeed resolved as "Wont Fix". So, yes, you are correct.
Unfixable. MC-31113
Unfixable. MC-31113
Unfixable. MC-31113
The bug
When writing in a book & quill and a word jumps to the next line on the last letter, it will jump back when the space bar is struck. However, in the signed book, that word will be on the next line and if the text on the page is over 13 lines long, a line of text will be lost. I have illustrated this in the screenshots below.
P.S.: Yes, I know this has been reported before but that report was written off as a duplicate to another issue that was not related. MC-78858 was not a duplicate of MC-31113.
Code analysis
Based on 1.11 decompiled using MCP 9.35 rc1
Automatic linebreak for valid text lengths while editing
The last word appears in the new line because the method net.minecraft.client.gui.GuiScreenBook.drawScreen(int, int, float) just appends the cursor (flashing _) to the text which increases the length. One possible approach to fix this might be to use the method net.minecraft.client.gui.GuiUtilRenderComponents.splitText(ITextComponent, int, FontRenderer, boolean, boolean) and then test if the cursor character can be appended to the last ITextComponent item and if not a new ITextComponentItem has to be added (this would probably solve the second bug as well).
Automatic linebreak while editing differs from signed version
The reason here is similar to the one for MC-83469 and is caused by the two different rendering methods.
net.minecraft.client.gui.GuiUtilRenderComponents.splitText(ITextComponent, int, FontRenderer, boolean, boolean) splits a string before the character which causes the string to exceed a given rendering width, whereas net.minecraft.client.gui.FontRenderer.drawSplitString(String, int, int, int, int) splits it after the character which exceeded the given width. (Please correct me here if I am wrong).
Resolving as a duplicate of MC-31113 which has been resolved as "Won't Fix".
Formatting with § is no longer supported and will no longer work properly in most parts of the game. Use text components instead.
Formatting codes using section signs have been deprecated for about a decade now and should no longer be used. Use JSON text instead.
Thank you for your report!
We're tracking this issue in MC-31113, so this ticket is being resolved and linked as a duplicate.
That ticket has already been resolved as working as intended, which means this is not considered a bug and won't be fixed. Please do not leave a comment on the linked ticket.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Thank you for your report!
We're tracking this issue in MC-31113, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
Invalid because of 3rd party tool.
Try to recreate that issue with /tellraw or /setblock
That filter was also taking advantage of a feature that was not really intended to be part of the commandblock.
If you use the command there http://minecraft.gamepedia.com/Chat#Chat for the text in color in a command block it won't work and only the first work will be in color.
Does that mean /say command won't support color anymore , as it is the only command for text that support @a @p @r command.
Minecraft basically is breaking all of old features without implementing a way to do it in a better way. With the /tellraw command you can easily create colored text, but can no longer use @p or @a, or @r. They need to implement a way to fix this. or map makers are screwed.
Dinnerbone's comment.