LemonCaramel
- LemonCaramel
- JIRAUSER562139
- Asia/Seoul
- Yes
- No
MC-202539
Low
If an opaque entity and semi-transparent block is behind a Semi-Transparent entity, it will not render properly.
In addition, if there is a portal behind a translucent block, it will not be rendered.
There was no problem when I used Minecraft 1.12.2.
If an opaque entity and semi-transparent block is behind a Semi-Transparent entity, it will not render properly.
In addition, if there is a portal or glass block behind a translucent block, it will not be rendered.
There was no problem when I used Minecraft 1.12.2.
Can't Fish with Fishing Rod or not spawn fishing bobber
Can'tFish with Fishing Rod or notspawn fishing bobber
Can't spawn fishing bobbernot spawn fishing bobber
Ping does not normally send to servers using SRV records.
Servers that do not use SRV records can be connected normally and pinged.
(Is it a problem after changing to Java 16?)
The below picture shows 1.16.5 on the right and 21w19a on the left.
First of all, I am sorry that my English is not good.
The Bug
ServerboundMovePlayerPacket's xRot can have invalid(90 over or -90 under) value.
An xRot value greater than 90 or less than -90 is an xRot value that players cannot have.
Can check it enter the command
/tp @s ~ ~ ~ ~ -180or look at the sky and enter the command
/tp @s ~ ~ ~ ~ ~-5In special cases, the client can also cause packet spam. (ex. send -95 to the server and immediately send -90)
Code analysis
net.minecraft.client.multiplayer.ClientPacketListenerUnable to find source-code formatter for language: code panel. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml@Override public void handleMovePlayer(ClientboundPlayerPositionPacket packet) { // ... localPlayer.setPos(d1, d3, d5); localPlayer.setDeltaMovement(d0, d2, d4); float f = packet.getYRot(); float f1 = packet.getXRot(); if (packet.getRelativeArguments().contains(ClientboundPlayerPositionPacket.RelativeArgument.X_ROT)) { // If the player's current xRot is -90 and the "float f1" is -1, the player's xRot will be -91. // and the client sends -91 to the server. localPlayer.setXRot(localPlayer.getXRot() + f1); localPlayer.xRotO += f1; // fix example (this would not be a good way) // localPlayer.setXRot(Mth.clamp(localPlayer.getXRot() + f1, -90.0F, 90.0F)); // localPlayer.xRotO = Mth.clamp(localPlayer.xRotO + f1, -90.0F, 90.0F); } else { // It's the same. localPlayer.setXRot(f1); localPlayer.xRotO = f1; } // ... this.connection.send(new ServerboundAcceptTeleportationPacket(packet.getId())); this.connection.send(new ServerboundMovePlayerPacket.PosRot(localPlayer.getX(), localPlayer.getY(), localPlayer.getZ(), localPlayer.getYRot(), localPlayer.getXRot(), false)); }
23w17a update fixed various notation problems related to Korean, but this update is being taken seriously by Koreans. Some Minecraft players in Korea are looking for ways to rollback fonts to their previous snapshots.
It's very difficult for us to read letters because the (Korean) consonants and vowels are not correctly positioned, and the sizes of each letter are all different.
For Example, 23w16a has almost the same size of all letters, but 23w17a does not.
Most of the letters are messy, but I only marked the difference that even those who don't know Hangul can easily to find out.
I think the easiest solution is to apply the new font. (most of modern unifont's Hangul is difficult to read.)
+ [Generating Hangul Syllables|https://unifoundry.com/hangul/hangul-generation.html] applied after unifont 5.1 seems to have created this terrible font.
23w17a update fixed various notation problems related to Korean, but this update is being taken seriously by Koreans. Some Minecraft players in Korea are looking for ways to rollback fonts to their previous snapshots.
It's very difficult for us to read letters because the (Korean) consonants and vowels are not correctly positioned, and the sizes of each letter are all different.
For Example, 23w16a has almost the same size of all letters, but 23w17a does not.
Most of the letters are messy, but I only marked the difference that even those who don't know Hangul can easily to find out.
I think the easiest solution is to apply the new font. (most of modern unifont's Hangul is difficult to read.)
+
[Generating Hangul Syllables|https://unifoundry.com/hangul/hangul-generation.html]applied after unifont 5.1 seems to have created this terrible font.23w17a update fixed various notation problems related to Korean, but this update is being taken seriously by Koreans. Some Minecraft players in Korea are looking for ways to rollback fonts to their previous snapshots.
It's very difficult for us to read letters because the (Korean) consonants and vowels are not correctly positioned, and the sizes of each letter are all different.
For Example, 23w16a has almost the same size of all letters, but 23w17a does not.
Most of the letters are messy, but I only marked the difference that even those who don't know Hangul can easily to find out.
I think the easiest solution is to apply the new font. (most of modern unifont's Hangul is difficult to read.)
+ Generating Hangul Syllables(https://unifoundry.com/hangul/hangul-generation.html) applied after unifont 5.1 seems to have created this terrible font.
23w17a update fixed various notation problems related to Korean, but this update is being taken seriously by Koreans. Some Minecraft players in Korea are looking for ways to rollback fonts to their previous snapshots.
It's very difficult for us to read letters because the (Korean) consonants and vowels are not correctly positioned, and the sizes of each letter are all different.
For Example, 23w16a has almost the same size of all letters, but 23w17a does not.
Most of the letters are messy, but I only marked the difference that even those who don't know Korean(Hangul) can easily to find out.
I think the easiest solution is to apply the new font. (most of modern unifont's Hangul is difficult to read.)
+ Generating Hangul Syllables(https://unifoundry.com/hangul/hangul-generation.html) applied after unifont 5.1 seems to have created this terrible font.
23w17a update fixed various notation problems related to Korean, but
this update is being taken seriously by Koreans. Some Minecraft players in Korea are looking for ways to rollback fonts to their previous snapshots.It's very difficult for us to read letters because the (Korean) consonants and vowels are not correctly positioned, and the sizes of each letter are all different.
For Example, 23w16a has almost the same size of all letters, but 23w17a does not.
Most of the letters are messy, but I only marked the difference that even those who don't know Korean(Hangul) can easily to find out.
I think the easiest solution is to apply the new font. (most of modern unifont's Hangul is difficult to read.)
+ Generating Hangul Syllables(https://unifoundry.com/hangul/hangul-generation.html) applied after unifont 5.1 seems to have created this terrible font.
This bug was introduced in 23w42a
Previously, the maximum string length of serialized components was 262144 characters, but starting from 23w42a, it has been changed to 32767. (Only writing. reading is still 262144)
How to Reproduce:
1. Set the ban reason for the player to be over 32704 characters.
2. Connect to the server.Stacktrace:
[15:11:15] [Netty Server IO #2/ERROR]: Error receiving packet 0 io.netty.handler.codec.EncoderException: String too big (was 32768 characters, max 32767) at uv.a(SourceFile:38) ~[server-1.20.4.jar:?] at ui.a(SourceFile:637) ~[server-1.20.4.jar:?] at ui.a(SourceFile:633) ~[server-1.20.4.jar:?] at afr.a(SourceFile:23) ~[server-1.20.4.jar:?] at um.a(SourceFile:47) ~[server-1.20.4.jar:?] at um.encode(SourceFile:15) ~[server-1.20.4.jar:?] at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107) ~[netty-codec-4.1.97.Final.jar:4.1.97.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:881) ~[netty-transport-4.1.97.Final.jar:4.1.97.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:863) ~[netty-transport-4.1.97.Final.jar:4.1.97.Final] at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:968) ~[netty-transport-4.1.97.Final.jar:4.1.97.Final] at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:856) ~[netty-transport-4.1.97.Final.jar:4.1.97.Final] at io.netty.handler.codec.MessageToMessageEncoder.write(MessageToMessageEncoder.java:113) ~[netty-codec-4.1.97.Final.jar:4.1.97.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:881) ~[netty-transport-4.1.97.Final.jar:4.1.97.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:940) ~[netty-transport-4.1.97.Final.jar:4.1.97.Final] at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:966) ~[netty-transport-4.1.97.Final.jar:4.1.97.Final] at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:934) ~[netty-transport-4.1.97.Final.jar:4.1.97.Final] at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:984) ~[netty-transport-4.1.97.Final.jar:4.1.97.Final] at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1025) ~[netty-transport-4.1.97.Final.jar:4.1.97.Final] at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:306) ~[netty-transport-4.1.97.Final.jar:4.1.97.Final] at ug.c(SourceFile:321) ~[server-1.20.4.jar:?] at ug.d(SourceFile:316) ~[server-1.20.4.jar:?] at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174) ~[netty-common-4.1.97.Final.jar:4.1.97.Final] at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167) ~[netty-common-4.1.97.Final.jar:4.1.97.Final] at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470) ~[netty-common-4.1.97.Final.jar:4.1.97.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569) ~[netty-transport-4.1.97.Final.jar:4.1.97.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.97.Final.jar:4.1.97.Final] at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.97.Final.jar:4.1.97.Final] at java.lang.Thread.run(Thread.java:840) ~[?:?]Code analysis:
... public class ClientboundLoginDisconnectPacket implements Packet<ClientLoginPacketListener> { ... public ClientboundLoginDisconnectPacket(FriendlyByteBuf buf) { this.reason = Component.Serializer.fromJsonLenient(buf.readUtf(FriendlyByteBuf.MAX_COMPONENT_STRING_LENGTH)); } @Override public void write(FriendlyByteBuf buf) { //buf.writeUtf(Component.Serializer.toJson(this.reason)); // Set the maximum component length correctly. buf.writeUtf(Component.Serializer.toJson(this.reason), FriendlyByteBuf.MAX_COMPONENT_STRING_LENGTH); } ...
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
LemonCaramel please could you state the precise gameplay impact that Mojang can diagnose and potentially triage this issue. In other words, how does this problem affect gameplay? You've mentioned that it occurs in vanilla; all we need now is an explanation of how this affects gameplay. Thanks 
You may not have known. singleplayer uses a way of open and join in multiplayer server.
singleplayer = open multiplayer server and join(If you check the Minecraft log, you can understand this method.)
In other words, the singleplayer server crashes enough.
I don't live in an English-speaking country. I hope you can understand what I'm saying.
Can confirm in 22w11a
I forgot to reply. It was resolved after switching to Fabulous, so you can close the issue.
MC-259376.mp4
There is no problem with 1.19.2 or less. (It's calibrated by the client)
yes The video I uploaded is Vanilla Client.
First, I was making a recoil(gun, helicopter and etc...) system. (using Relative Teleport)
However, this bug prevents me from performing the intended action.
-------
As you can see in the video, the player can take actions that are impossible.
-------
From the viewpoint of the third-party server operator(or Developer)
From the viewpoint of the player
From the viewpoint of the content creator
There are too many omitted expressions because I am not good at English. I'm sorry.
I was very disappointed with Mojang's response, and I think they treated Koreans poorly.
They didn't even explain why they won’t fix this issue.
And among many languages, only Korean has changed to be difficult to read.
I know, this is Unifont's fault. but Mojang choose Unifont among the other fonts. Isn't it?
Mojang is no longer an indie game company. Before making these font changes, the local community has to confirm that there are no problem, and if there are, Mojang should resolve it.
It doesn't seem to be right to pass over responsibility on customer to solve Unifont issue.
This is never a minor issue and should be fixed before 1.20 release. Please reconsider this issue, Mojang.
Ban reason is converted to JSON component format when sent to the player.
The converted ban reason always has the following format. (64 number of characters)
{"translate":"multiplayer.disconnect.banned.reason","with":[""]}To trigger the error, it needs to exceed 32767 characters(32768+), so 32704 characters or more is correct.
This issue has been fully fixed in 24w36a with the teleport refactoring. Players no longer send incorrect xRot values to the server, no longer spam packets, and no longer show impossible rotation behavior when the chat screen is open.
Confirmed in 24w37a