mojira.dev

Jordin Smith

Assigned

No issues.

Reported

MC-94028 Attack Strength Desync Between Client and Server Awaiting Response MC-88416 Random Crash on snapshot Duplicate MC-63026 Gamemode 3 (spectator) is useless underground [FIXED in 14w31a] Fixed MC-46468 New "barrier" block causes NullPointerException Duplicate MC-33467 Summoning a FireWork crash when using non-decimal colour values Fixed MC-1313 macOS: Incorrect sign surface normal causes the text colour to not be applied properly Fixed

Comments

I tried to test it yesterday but I was still running an older snapshot for some reason. I attempted to remove those versions when I realized but I guess it didn't work. The only version I am able to change is 1.14.4 (where the bug still occurs), all the others versions are archived and I cannot change them.

I was not able to reproduce this bug in 19w39a or 19w40a.

This bug appears to have been fixed in 19w39a. I tested it on my old macbook and the sign rendering was broken in 19w38b but worked fine in 19w39a and 19w40a. Looking at the source, it looks like they removed the offending normal3f() in 19w39a.

Although, with all the changes to the rendering and new issues with signs, I wouldn't be surprised if they reverted this change back, reintroducing the bug. But for now, it appears to be fixed.

Sorry, I was only leaving a comment because FVbico told me to, I'll stop leaving them now

This is still an issue for macOS on 1.13-pre9.

This issue is still present in 1.13-pre8.

This is still an issue on 1.13-pre7.

This is still an issue on 1.13-pre6. I also updated the bug report with more details.

This is still an issue on 1.12.2 and 1.13-pre2 on a Macbook Pro.

Yes that is the problem. If you are not using a touchscreen you should turn it off. The touchscreen mode assumes you will be pressing down for more than just an instant like a mouse click. This is not a bug.

Did you accidentally enable touchscreen mode?

This is still an issue in 16w21b.
Also, do you mods get a notification if I edit a previous comment? I hate spamming this every update. If not, is it ok if I remove the old messages (every one except the latest)?

This is also in 16w21a.

This is still not fixed on the 1.10 snapshot 16w20a.

This is still an issue in 1.9.3-pre1 and 16w15b.

This is still an issue in 1.9.1 and 1.9.2. I'm not sure if it counts but this issue seems to be fixed in 1.RV-Pre1 The Trendy Update (the 2016 April Fools joke). I believe we should wait until the next actual version comes out before marking this as resolved.

This is still an issue on full release 1.9.

Still an issue in 1.9-pre4.

Yes this is still in 1.9-pre2, and in 1.9-pre3, I added some screenshots showing it (using Attach Files). Later today I can provide the way to fix it in 1.9-pre3.

Happens to me running Java 8 on OS X 10.11 El Capitan. I have found a way to fix it, below is a method of fixing it using MCP mappings:

Go to TileEntitySignRenderer.java
Look for the method: renderTileEntityAt(TileEntitySign, double, double, double, float, int)
Find float f3 = 0.015625F * f;
The third line after that uses this float: GL11.glNormal3f(0.0F, 0.0F, -1.0F * f3); (Probably using GlStateManager but MCP changed it)
Changing this line to not use a negative number fixes it, example:
GL11.glNormal3f(0.0F, 0.0F, 1.0F * f3);
or, more simply:
GL11.glNormal3f(0.0F, 0.0F, f3);
(this is right after you bind the sign texture, right before you disable depth mask)

Using 1.9-pre2 obfuscated:
Go to bps.class
Look for the method: public void a(aqm, double, double, double, float, int)
Find: float \u2603 = 0.015625F * \u2603;
The third line after that uses this float: bnh.a(0.0F, 0.0F, -1.0F * \u2603);
Changing this line to not use a negative number fixes it, example:
bnh.a(0.0F, 0.0F, \u2603);
(this is right after you bind the sign texture, right before you disable depth mask)