Pasting the char （ in any Textbox will make Text after it invisible. If you set it as World Name you still can use the world, but the Text in the Box is missing. This makes Worlds without Names possible.
Please note, that the char is not an open parenthese and you need to copy-paste it. The Directory created for the world contains this char and looks regular.
Linked issues
Attachments
Comments 16
Textboxexes seem to accept most UTF-8 chars.
Version 1.5 is still affected
Fix
FontRenderer.renderUnicodeChar(char c, boolean italic)
...
//int startColumn = this.glyphWidth[c] >>> 4;
int startColumn = (this.glyphWidth[c] >>> 4) & 15; // FIX
...Tested on 1.4.7, works wonders.
Reason was that the byte for 'glyph width' is handled as unsigned value, whereas Java only does stuff as signed values (except 'char' of course) and bit-operations in 32-bit things. Before doing the bitshift (which does have the nice >>> op), it will sign-extend the byte. If the high nibble has large enough value (8..15), it basically means the byte has negative value, and thus the 32-bit integer being shifted is also negative and has 24 extra 1-bits on left. After the shift, such integer value converts into a very large positive value. The start column was thus calculated to be a very, very, very large thing, causing multiple problems, like rendered width to be millions of pixels. (The rest of text was thus way past the visible area.)
For that particular character used in the description: its codepoint is 65288, glyph width value -100 (or nibbles 9 and 12), and the shifted result for start column 268435449!
instead of int it would be better to use an unsigned int. wouldn't this solve the problem?
Kevin, I recommend reading my analysis more carefully, or alternately, reading Java language specification. Basically, Java does not have unsigned integer values. The only exception is 'char', which is basically unsigned 16-bit integer with a little bit of unicode related sugar. Unfortunately, as soon as any kind of math/bit-operation is done with such value, it is implicitly converted into 32-bit signed ints, and all kinds of headaches and keyboard throwing contests ensue.
But yes, using such unsigned integer value would have done the trick.
Updated the issue, still present in 1.6.1
Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Still in 1.6.2
Is this still a concern in the current Minecraft version 1.7.4 / Launcher version 1.3.8 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Still affects 1.7.4/5 and 1.8
Confirmed for 14w18b.
Yes it is still a concern with the newest version
Reopened, thanks
Duplicates MC-13046
Original descriptions are somewhat different, but indeed, the same cause (incorrectly calculated widths) is behind these issues. So yes, a duplicate. (Marcono and I even found the same fix independently.)
Example of an empty name due to UTF-8 Bug