![[Mod] Nassim Jahnke](../../../data/avatars/users/94205.png)
[Mod] Nassim Jahnke
- kennytv
- kennytv
- Europe/Stockholm
- Yes
- No
![[Mojang] Gegy](../../../data/avatars/users/10122.svg){kind=small}
![[Mojang] Georgii Gavrichev](../../../data/avatars/users/22428.png){kind=small}
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
![[Mojang] Billy Sjöberg](../../../data/avatars/users/42806.png){kind=small}
MC-279971
Sprintingfrom a one block tall water source into a seelets you "walk" onwaterSprinting when being just one block into water lets you "walk" on it
Editing (already once edited) books with colored content makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or color code becomes visable) being deleted when removing characters.
More notably, when having the last line with no characters, selecting it and pressing backspace, results in the following crash (same when selecting more text by holding the left mouse):
java.lang.StringIndexOutOfBoundsException: String index out of range: 240java.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$1952/745868137.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1502/1631805946.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Editing (already once edited) books with colored content makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or color code becomes visable) being deleted when removing characters.
More notably, when having the last line with no characters, selecting it and pressing backspace, results in the following crash (same when selecting more text by holding the left mouse):
java.lang.StringIndexOutOfBoundsException: String index out of range: 240java.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$1952/745868137.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1502/1631805946.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Editing (already once edited) books with colored content makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or color code becomes visable) being deleted when removing characters.
More notably, when having the last line with no characters, selecting it and pressing backspace, results in the following crash (same when selecting more text by holding the left mouse):
---- Minecraft Crash Report -------- Minecraft Crash Report ----// My bad.
Time: 26.04.19 12:50Description: keyPressed event handler
java.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$1952/745868137.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1502/1631805946.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)A detailed walkthrough of the error, its code path and all known details is as follows:---------------------------------------------------------------------------------------
– Head --Thread: Client threadStacktrace: at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$1952/745868137.run(Unknown Source)
– Affected screen --Details: Screen name: daqStacktrace: at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1502/1631805946.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283)
– Affected level --Details: Level name: MpServer All players: 1 total; [djv['KennyTV'/276, l='MpServer', x=8.45, y=65.00, z=-90.41]] Chunk stats: MultiplayerChunkCache: 729, 462 Level seed: 0 Level generator: ID 00 - default, ver 1. Features enabled: false Level generator options: {} Level spawn location: World: (-25,64,-96), Chunk: (at 7,4,0 in -2,-6; contains blocks -32,0,-96 to -17,255,-81), Region: (-1,-1; contains chunks -32,-32 to -1,-1, blocks -512,0,-512 to -1,255,-1) Level time: 3929 game time, 24617 day time Level dimension: 0 Level storage version: 0x00000 - Unknown? Level weather: Rain time: 0 (now: false), thunder time: 0 (now: false) Level game mode: Game mode: survival (ID 0). Hardcore: false. Cheats: false Server brand: Spigot Server type: Non-integrated multiplayer serverStacktrace: at dhl.a(SourceFile:421) at cvi.b(SourceFile:1920) at cvi.b(SourceFile:426) at net.minecraft.client.main.Main.main(SourceFile:154)
– System Details --Details: Minecraft Version: 1.14 Operating System: Windows 10 (amd64) version 10.0 Java Version: 1.8.0_51, Oracle Corporation Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation Memory: 641439856 bytes (611 MB) / 1125036032 bytes (1072 MB) up to 4214489088 bytes (4019 MB) JVM Flags: 26 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xss1M -Xmx4G -Xmn768m -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseNUMA -XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=15 -XX:MaxGCPauseMillis=30 -XX:GCPauseIntervalMillis=150 -XX:+UseAdaptiveGCBoundary -XX:-UseGCOverheadLimit -XX:+UseBiasedLocking -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=15 -XX:+UseFastAccessorMethods -XX:+UseCompressedOops -XX:+OptimizeStringConcat -XX:+AggressiveOpts -XX:ReservedCodeCacheSize=1024m -XX:+UseCodeCacheFlushing -XX:SoftRefLRUPolicyMSPerMB=2000 -XX:ParallelGCThreads=10 Launched Version: 1.14 LWJGL: 3.2.1 build 12 OpenGL: GeForce GTX 980 Ti/PCIe/SSE2 GL version 4.6.0 NVIDIA 418.81, NVIDIA Corporation GL Caps: Using GL 1.3 multitexturing.Using GL 1.3 texture combiners.Using framebuffer objects because OpenGL 3.0 is supported and separate blending is supported.Shaders are available because OpenGL 2.1 is supported.VBOs are available because OpenGL 1.5 is supported.
Using VBOs: Yes Is Modded: Probably not. Jar signature remains and client brand is untouched. Type: Client (map_client.txt) Resource Packs: vanilla, file/Faithful.zip Current Language: English (US) CPU: 12x Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
Editing (already once edited) books with colored content makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or color code becomes visable) being deleted when removing characters.
More notably, when having the last line with no characters, selecting it and pressing backspace, results in the following crash (same when selecting more text by holding the left mouse):
---- Minecraft Crash Report -------- Minecraft Crash Report ----// My bad.
Time: 26.04.19 12:50Description: keyPressed event handler
java.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$1952/745868137.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1502/1631805946.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)A detailed walkthrough of the error, its code path and all known details is as follows:---------------------------------------------------------------------------------------
– Head --Thread: Client threadStacktrace: at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$1952/745868137.run(Unknown Source)
– Affected screen --Details: Screen name: daqStacktrace: at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1502/1631805946.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283)
– Affected level --Details: Level name: MpServer All players: 1 total; [djv['KennyTV'/276, l='MpServer', x=8.45, y=65.00, z=-90.41]] Chunk stats: MultiplayerChunkCache: 729, 462 Level seed: 0 Level generator: ID 00 - default, ver 1. Features enabled: false Level generator options: {} Level spawn location: World: (-25,64,-96), Chunk: (at 7,4,0 in -2,-6; contains blocks -32,0,-96 to -17,255,-81), Region: (-1,-1; contains chunks -32,-32 to -1,-1, blocks -512,0,-512 to -1,255,-1) Level time: 3929 game time, 24617 day time Level dimension: 0 Level storage version: 0x00000 - Unknown? Level weather: Rain time: 0 (now: false), thunder time: 0 (now: false) Level game mode: Game mode: survival (ID 0). Hardcore: false. Cheats: false Server brand: Spigot Server type: Non-integrated multiplayer serverStacktrace: at dhl.a(SourceFile:421) at cvi.b(SourceFile:1920) at cvi.b(SourceFile:426) at net.minecraft.client.main.Main.main(SourceFile:154)
– System Details --Details: Minecraft Version: 1.14 Operating System: Windows 10 (amd64) version 10.0 Java Version: 1.8.0_51, Oracle Corporation Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation Memory: 641439856 bytes (611 MB) / 1125036032 bytes (1072 MB) up to 4214489088 bytes (4019 MB) JVM Flags: 26 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xss1M -Xmx4G -Xmn768m -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseNUMA -XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=15 -XX:MaxGCPauseMillis=30 -XX:GCPauseIntervalMillis=150 -XX:+UseAdaptiveGCBoundary -XX:-UseGCOverheadLimit -XX:+UseBiasedLocking -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=15 -XX:+UseFastAccessorMethods -XX:+UseCompressedOops -XX:+OptimizeStringConcat -XX:+AggressiveOpts -XX:ReservedCodeCacheSize=1024m -XX:+UseCodeCacheFlushing -XX:SoftRefLRUPolicyMSPerMB=2000 -XX:ParallelGCThreads=10 Launched Version: 1.14 LWJGL: 3.2.1 build 12 OpenGL: GeForce GTX 980 Ti/PCIe/SSE2 GL version 4.6.0 NVIDIA 418.81, NVIDIA Corporation GL Caps: Using GL 1.3 multitexturing.Using GL 1.3 texture combiners.Using framebuffer objects because OpenGL 3.0 is supported and separate blending is supported.Shaders are available because OpenGL 2.1 is supported.VBOs are available because OpenGL 1.5 is supported.
Using VBOs: Yes Is Modded: Probably not. Jar signature remains and client brand is untouched. Type: Client (map_client.txt) Resource Packs: vanilla, file/Faithful.zip Current Language: English (US) CPU: 12x Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
Editing (already once edited) books with colored content makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or color code becomes visable) being deleted when removing characters.
More notably, when having the last line with no characters, selecting it and pressing backspace, results in the following crash (same when selecting more text by holding the left mouse):
java.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$1952/745868137.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1502/1631805946.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Yep @violine1101, attached it
Editing (already once edited) books with colored content makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or
color code becomes visable) being deleted when removing characters.More notably, when having the last line with no characters, selecting it and pressing backspace, results in the following crash (same when selecting
more text by holding the left mouse):java.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$1952/745868137.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1502/1631805946.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character) being deleted when removing characters.
More notably, when having the last line with no characters, selecting it and pressing backspace, results in the following crash (same when selecting text containing the mentioned):
java.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$1952/745868137.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1502/1631805946.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character) being deleted when removing characters.
More notably, when having the last line with no characters (+ closing and then reopening), selecting it and pressing backspace, results in the following crash (same when selecting text containing the mentioned):
java.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$1952/745868137.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1502/1631805946.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character) being deleted when removing characters.
More notably, when having the last line with no characters but the unshown text (+ closing and then reopening), selecting it and pressing backspace, results in the following crash (same when selecting text containing the mentioned):
java.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$1952/745868137.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1502/1631805946.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
crash-2019-04-26_12.50.16-client.txt
Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character) being deleted when removing characters.
More notably, when having the last line with no characters but the unshown text (+ closing and then reopening), selecting it and pressing backspace, results in the following crash (same when selecting text containing the mentioned):
1.14: [^crash-2019-04-26_14.56.24-client.txt]java.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$2032/1782324054.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1536/1183266411.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
More notably, when having the last line with no characters but the unshown text (+ closing and then reopening), selecting it and pressing backspace, results in the following crash (same when selecting text containing the mentioned):
1.14: crash-2019-04-26_14.56.24-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$2032/1782324054.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1536/1183266411.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
More notably, when having the last line with no characters but the unshown text (+ closing and then reopening), selecting it and pressing backspace, results in the following crash (same when selecting text containing the mentioned):
Steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, paste any text with '§' characters in a book, save world
- start a 1.14(.1 pre) client, convert/open the world, open the books
to find errors:
- try to click on the very last character -> crash
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etext1.14: crash-2019-04-26_14.56.24-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$2032/1782324054.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1536/1183266411.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
More notably, when having the last line with no characters but the unshown text (+ closing and then reopening), selecting it and pressing backspace, results in the following crash (same when selecting text containing the mentioned):
Steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, paste any text with '§' characters in a book, save world
- start a 1.14(.1 pre) client, convert/open the world, open the book
s
to find errors:
try toclick onthe verylast character -> crashi.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etext1.14: crash-2019-04-26_14.56.24-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$2032/1782324054.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1536/1183266411.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, paste any text with '§' characters in a book, save world
- start a 1.14(.1 pre) client, convert/open the world, open the book
What can be ovserved:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterwards
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually seletected position
This means that on a click in lines containing '§' the position is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etext1.14: crash-2019-04-26_14.56.24-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$2032/1782324054.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1536/1183266411.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, paste any text with '§' characters in a book, save world
- start a 1.14(.1 pre) client, convert/open the world, open the book
What can be ovserved:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterwards
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually seletected position
This means that on a click in lines containing '§' the position is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etext1.14: crash-2019-04-26_14.56.24-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$2032/1782324054.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1536/1183266411.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, paste any text with '§' characters in a book, save world
- start a 1.14(.1 pre) client, convert/open the world, open the book
What can be ovserved:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterwards
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually seletected position
This means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etext1.14: crash-2019-04-26_14.56.24-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$2032/1782324054.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1536/1183266411.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world
- start a 1.14(.1 pre) client, convert/open the world, open the book
What can be ovserved:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterwards
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually seletected position
This means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etext1.14: crash-2019-04-26_14.56.24-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$2032/1782324054.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1536/1183266411.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Upgraded 1.13.2 world with written (yet unsigned) books on a Vanilla 1.14 server
Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world
- start a 1.14
(.1 pre) client, convert/open the world, open the bookWhat can be ovserved:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterwards
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually seletected position
This means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etext1.14: crash-2019-04-26_14.56.24-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$2032/1782324054.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1536/1183266411.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world
- start a 1.14.(1) client, convert/open the world, open the book
What can be ovserved:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterwards
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually seletected position
This means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etext1.14: crash-2019-04-26_14.56.24-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$2032/1782324054.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1536/1183266411.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world
- start a 1.14.(1) client, convert/open the world, open the book
What can be ovserved:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterwards
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually seletected position
This means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etext1.14: crash-2019-04-26_14.56.24-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daq.b(SourceFile:322) at daq.b(SourceFile:278) at daq.keyPressed(SourceFile:229) at cvg.a(SourceFile:409) at cvg$$Lambda$2032/1782324054.run(Unknown Source) at czr.wrapScreenError(SourceFile:441) at cvg.a(SourceFile:407) at cvg$$Lambda$1536/1183266411.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cub.l(SourceFile:425) at cub.c(SourceFile:283) at cvi.b(SourceFile:1023) at cvi.d(SourceFile:976) at cvi.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world
- start a 1.14.(1) client, convert/open the world, open the book
What can be ovserved:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterwards
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually seletected position
This means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etext1.14.1: crash-2019-05-13_18.36.41-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 240 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at das.b(SourceFile:322) at das.b(SourceFile:278) at das.keyPressed(SourceFile:229) at cvi.a(SourceFile:410) at cvi$$Lambda$3140/1695127472.run(Unknown Source) at czt.wrapScreenError(SourceFile:441) at cvi.a(SourceFile:408) at cvi$$Lambda$1518/1679714298.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cud.l(SourceFile:425) at cud.c(SourceFile:283) at cvk.b(SourceFile:1023) at cvk.e(SourceFile:976) at cvk.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world
- start a 1.14.
(1)client, convert/open the world, open the bookWhat can be ovserved:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterwards
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually seletected position
This means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etext1.14.1: crash-2019-05-13_18.36.41-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range:240at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at das.b(SourceFile:322) at das.b(SourceFile:278) at das.keyPressed(SourceFile:229) at cvi.a(SourceFile:410) at cvi$$Lambda$3140/1695127472.run(Unknown Source) at czt.wrapScreenError(SourceFile:441) at cvi.a(SourceFile:408) at cvi$$Lambda$1518/1679714298.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3050) at cud.l(SourceFile:425) at cud.c(SourceFile:283) at cvk.b(SourceFile:1023) at cvk.e(SourceFile:976) at cvk.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world
- start a 1.14.x client, convert/open the world, open the book
What can be ovserved:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterwards
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually seletected position
This means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etext1.14.3: crash-2019-06-24_17.38.29-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 58 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daw.b(SourceFile:322) at daw.b(SourceFile:278) at daw.keyPressed(SourceFile:229) at cvm.a(SourceFile:410) at cvm$$Lambda$3114/1251831481.run(Unknown Source) at czx.wrapScreenError(SourceFile:441) at cvm.a(SourceFile:408) at cvm$$Lambda$1517/1811787479.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3101) at cuh.l(SourceFile:425) at cuh.c(SourceFile:283) at cvo.b(SourceFile:1023) at cvo.e(SourceFile:976) at cvo.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world
- start a 1.14.x client, convert/open the world, open the book
Or use the following command in 1.14.x:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}What can be o
vserved:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterward
s- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually sele
tected positionThis means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etext1.14.3: crash-2019-06-24_17.38.29-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 58 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daw.b(SourceFile:322) at daw.b(SourceFile:278) at daw.keyPressed(SourceFile:229) at cvm.a(SourceFile:410) at cvm$$Lambda$3114/1251831481.run(Unknown Source) at czx.wrapScreenError(SourceFile:441) at cvm.a(SourceFile:408) at cvm$$Lambda$1517/1811787479.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3101) at cuh.l(SourceFile:425) at cuh.c(SourceFile:283) at cvo.b(SourceFile:1023) at cvo.e(SourceFile:976) at cvo.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world
- start a 1.14.x client, convert/open the world, open the book
Or use the following command in 1.14.x:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}What can be observed:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterward
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually selected position
This means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etextA different
stacktrace/crash-log, created in 1.15.2, has been attached to the files.
1.14.3: crash-2019-06-24_17.38.29-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 58 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daw.b(SourceFile:322) at daw.b(SourceFile:278) at daw.keyPressed(SourceFile:229) at cvm.a(SourceFile:410) at cvm$$Lambda$3114/1251831481.run(Unknown Source) at czx.wrapScreenError(SourceFile:441) at cvm.a(SourceFile:408) at cvm$$Lambda$1517/1811787479.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3101) at cuh.l(SourceFile:425) at cuh.c(SourceFile:283) at cvo.b(SourceFile:1023) at cvo.e(SourceFile:976) at cvo.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world
- start a 1.14.x client, convert/open the world, open the book
Or use the following command in 1.14.x:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}What can be observed:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterward
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually selected position
This means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etextA different
stacktrace/crash-log, created in 1.15.2, has been attached to the files.1.14.3: crash-2019-06-24_17.38.29-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 58 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daw.b(SourceFile:322) at daw.b(SourceFile:278) at daw.keyPressed(SourceFile:229) at cvm.a(SourceFile:410) at cvm$$Lambda$3114/1251831481.run(Unknown Source) at czx.wrapScreenError(SourceFile:441) at cvm.a(SourceFile:408) at cvm$$Lambda$1517/1811787479.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3101) at cuh.l(SourceFile:425) at cuh.c(SourceFile:283) at cvo.b(SourceFile:1023) at cvo.e(SourceFile:976) at cvo.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world
- start a 1.14.x client, convert/open the world, open the book
Or use the following command in 1.14.x:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}What can be observed:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterward
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually selected position
This means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etextThe older 1.14.3 crash log had a different stacktrace
1.14.3: crash-2019-06-24_17.38.29-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 58 at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daw.b(SourceFile:322) at daw.b(SourceFile:278) at daw.keyPressed(SourceFile:229) at cvm.a(SourceFile:410) at cvm$$Lambda$3114/1251831481.run(Unknown Source) at czx.wrapScreenError(SourceFile:441) at cvm.a(SourceFile:408) at cvm$$Lambda$1517/1811787479.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3101) at cuh.l(SourceFile:425) at cuh.c(SourceFile:283) at cvo.b(SourceFile:1023) at cvo.e(SourceFile:976) at cvo.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)
Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world
- start a 1.14.x client, convert/open the world, open the book
Or use the following command in 1.14.x:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}What can be observed:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterward
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually selected position
This means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etextThe older 1.14.3 crash log had a different stacktrace
1.14.3: crash-2019-06-24_17.38.29-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range:58at java.lang.AbstractStringBuilder.deleteCharAt(AbstractStringBuilder.java:797) at java.lang.StringBuilder.deleteCharAt(StringBuilder.java:253) at daw.b(SourceFile:322) at daw.b(SourceFile:278) at daw.keyPressed(SourceFile:229) atcvm.a(SourceFile:410) atcvm$$Lambda$3114/1251831481.run(Unknown Source) at czx.wrapScreenError(SourceFile:441) atcvm.a(SourceFile:408) atcvm$$Lambda$1517/1811787479.invoke(Unknown Source) at org.lwjgl.glfw.GLFWKeyCallbackI.callback(GLFWKeyCallbackI.java:37) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3101) at cuh.l(SourceFile:425) at cuh.c(SourceFile:283) at cvo.b(SourceFile:1023) atcvo.e(SourceFile:976) atcvo.b(SourceFile:411) at net.minecraft.client.main.Main.main(SourceFile:154)Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world
- start a 1.14.x client, convert/open the world, open the book
Or use the following command in 1.14.x:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}What can be observed:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterward
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually selected position
This means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etextThe older 1.14.3 crash log had a different stacktrace
1.15.2: crash-2020-04-28_15.38.46-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 44 at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:48) at java.base/java.lang.String.charAt(String.java:711) at dch.a(SourceFile:454) at dha.mouseClicked(SourceFile:779) at dbo.b(SourceFile:86) at dgb.wrapScreenError(SourceFile:447) at dbo.a(SourceFile:86) at dbo.c(SourceFile:150) at ais.execute(SourceFile:94) at dbo.b(SourceFile:150) at org.lwjgl.glfw.GLFWMouseButtonCallbackI.callback(GLFWMouseButtonCallbackI.java:36) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3101) at com.mojang.blaze3d.systems.RenderSystem.flipFrame(SourceFile:98) at cxx.e(SourceFile:301) at dbn.d(SourceFile:1012) at dbn.d(SourceFile:619) at net.minecraft.client.main.Main.main(SourceFile:204)
-I still can. The trace seems a little different, but I reproduced it by just randomly clicking around the lines. I uploaded 2 crash logs for 1.15.2 (both apparently different), and here's a video of the crash https://streamable.com/ca2ai4-
Edit: whoops overread the 20w17a part - but could still get to the same result there
Editing (already once edited) books with colored content/'§' makes the client mismatch the actual character length, resulting in either one character too much (takes away another character) or too less (= § or following character still left) being deleted when removing characters.
Concrete steps to reproduce:
- start a 1.13.2 client, create a new singleplayer world, copy and paste any text with '§' characters in a book (see below), save world
- start a 1.14.x client, convert/open the world, open the book
Or use the following command in 1.14.x:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}What can be observed:
- clicking on or marking the last character of the book -> crash
- going to the last character with the right arrow doesn't go to the very end, but stops at a character before it
- trying to remove characters where a '§' is results in seemingly the wrong character being removed
- removing '§' characters with the delete key doesn't remove the character setting the color afterward
- most notably: clicking the front on the second last line, then pressing the delete/backspace key removes characters a few letters behind the actually selected position
This means that on a click in lines containing '§' the position/character length is calculated wrongly
i.e. copy and paste
§nVery cool text §r §§§§ hi §5and even more §etextThe older 1.14.3 crash log had a different stacktrace
1.15.2: crash-2020-04-28_15.38.46-client.txtjava.lang.StringIndexOutOfBoundsException: String index out of range: 44 at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:48) at java.base/java.lang.String.charAt(String.java:711) at dch.a(SourceFile:454) at dha.mouseClicked(SourceFile:779) at dbo.b(SourceFile:86) at dgb.wrapScreenError(SourceFile:447) at dbo.a(SourceFile:86) at dbo.c(SourceFile:150) at ais.execute(SourceFile:94) at dbo.b(SourceFile:150) at org.lwjgl.glfw.GLFWMouseButtonCallbackI.callback(GLFWMouseButtonCallbackI.java:36) at org.lwjgl.system.JNI.invokeV(Native Method) at org.lwjgl.glfw.GLFW.glfwPollEvents(GLFW.java:3101) at com.mojang.blaze3d.systems.RenderSystem.flipFrame(SourceFile:98) at cxx.e(SourceFile:301) at dbn.d(SourceFile:1012) at dbn.d(SourceFile:619) at net.minecraft.client.main.Main.main(SourceFile:204)
Loading bow in offhand and switching to shield in main hand causesvisual glitchLoading bow in offhand and switching to shield in main hand causes straitened bow to be held downwards
Loading bow in offhand andswitching to shield inmain hand causesstraitenedbow to be held downwardsLoading bow with shield in off hand and left as main hand causes bow to be held downwards
Firstly the
When loading a bow in the off hand, then switching to a shield in the main hand, the loaded bow is being held down (when releasing the mouse button the arrow is fired as usual).
Firstly the
When loading a bow in the off hand, then switching to a shield in the main hand, the loaded bow is being held down (when releasing the mouse button the arrow is fired as usual).
Firstly, loading bow with shield in off hand and left as main hand causes bow to be held downwards.
The same effect (but with the right hand as main hand) can be replicatedwhen loading a bow in the off hand, then switching to a shield in the main hand, the loaded bow is being held down (when releasing the mouse button the arrow is fired as usual).
Firstly, loading bow with shield in off hand and left as main hand causes bow to be held downwards.
The same effect (but with the right hand as main hand) can be replicatedwhen loading a bow in the off hand, then switching to a shield in the main hand, the loaded bow is being held down (when releasing the mouse button the arrow is fired as usual).
... Thirdly, doing the the same as described in th
Velocity resets when digging and changing target to an instantly brokenblockVelocity resets when digging and changing target to an instantly breakable block
Probably due to the changes made for https://bugs.mojang.com/browse/MC-149792
Client velocity is reset (due to the new packet being sent) when you do the following:
continously keep going/movinglook at the ground,start (and keep) diggingshowcased best on fields with lots of flowers/grass:destroy some of those instantly breakable blocks along the way-> velocity is reset
Note: the method above is the easiest to just do, but it obviously works in any similar case, e.g.
- start moving
- using an efficiency 5 pickaxe: start and keep digging dirt/grass blocks/any other block that isn't digged fast enough to be broken before going to the next block
- go over blocks that are instantly broken with that tool (i.e. netherrack)
Probably due to the changes made for https://bugs.mojang.com/browse/MC-149792
Client velocity is reset (due to the new packet being sent) when you do the following:
- move (so that the velocity reset becomes visable)
- start digging a block (that isn't yet broken before switching to the next one in the next step)
- while keeping the dig button pressed: look over to a neighboured block that is instantly breakable (grass, flowers, netherrack with an efficiency pickaxe, etc.)
-> velocity is reset
Probably due to the changes made for https://bugs.mojang.com/browse/MC-149792
Client velocity is reset (due to the new packet being sent) when you do the following:
- move (so that the velocity reset becomes visable)
- start digging a block (that isn't yet broken before switching to the next one in the next step)
- while keeping the dig button pressed: look over to a neighboured block that is instantly breakable (grass, flowers, netherrack with an efficiency pickaxe, etc.)
-> velocity is reset
The easiest way to set this up is by going over a field with grass (or an effiency 5 pickaxe and netherrack, starting with a block that is not instantly mineable with a pickaxe -> not instantly mineable block next to an instantly mineable block)
Probably due to the changes made for
https://bugs.mojang.com/browse/MC-149792Client velocity is reset (due to the new packet being sent) when you do the following:
- move (so that the velocity reset becomes visable)
- start digging a block (that isn't yet broken before switching to the next one in the next step)
- while keeping the dig button pressed: look over to a neighboured block that is instantly breakable (grass, flowers, netherrack with an efficiency pickaxe, etc.)
-> velocity is reset
The easiest way to set this up is by going over a field with grass (or an effiency 5 pickaxe and netherrack, starting with a block that is not instantly mineable with a pickaxe -> not instantly mineable block next to an instantly mineable block)
Probably due to the changes made for https://bugs.mojang.com/browse/MC-156013
Client velocity is reset (due to the new packet being sent) when you do the following:
- move (so that the velocity reset becomes visable)
- start digging a block (that isn't yet broken before switching to the next one in the next step)
- while keeping the dig button pressed: look over to a neighboured block that is instantly breakable (grass, flowers, netherrack with an efficiency pickaxe, etc.)
-> velocity is reset
The easiest way to set this up is by going over a field with grass (or an effiency 5 pickaxe and netherrack, starting with a block that is not instantly mineable with a pickaxe -> not instantly mineable block next to an instantly mineable block)
Velocity resets whendigging and changing target to an instantly breakable blockVelocity resets when breaking blocks occasionally
Insta mining blocks (e.g. dirt with an efficiency 5 diamond shovel) occasionally leaves behind ghost blocks, of which there still is a serverside hitbox but the client counts it as already digged.
This happens quite often - just going around like this produces one mismatched block every few seconds.As I cannot reproduce this in any pre-release prior to pre4 (so I can in 4, 5, and 6), I believe this is related to the new packet/fix for https://bugs.mojang.com/browse/MC-156013
See the attached video.
Insta mining blocks (e.g. dirt with an efficiency 5 diamond shovel) occasionally leaves behind ghost blocks, of which there still is a serverside hitbox but the client counts it as already digged.
This happens quite often - just going around like this produces one mismatched block every few seconds.As I cannot reproduce this in any pre-release prior to pre4 (so I can in 4, 5, and 6), I believe this is related to the new packet/fix for https://bugs.mojang.com/browse/MC-156013
See the attached video, reproducing the bug in a freshly created singleplayer world (I also waited for generation to calm down before starting to dig).
Insta mining blocks (e.g. dirt with an efficiency 5 diamond shovel) occasionally leaves behind ghost blocks, of which there still is a serverside hitbox but the client counts it as already digged.
This happens quite often - just going around like this produces one mismatched block every few seconds.As I cannot reproduce this in any pre-release prior to pre4 (so I can
in 4, 5, and 6), I believe this is related to the new packet/fix for https://bugs.mojang.com/browse/MC-156013See the attached video, reproducing the bug in a freshly created singleplayer world (I also waited for generation to calm down before starting to dig).
Insta mining blocks (e.g. dirt with an efficiency 5 diamond shovel) occasionally leaves behind ghost blocks, of which there still is a serverside hitbox but the client counts it as already digged.
This happens quite often - just going around like this produces one mismatched block every few seconds.As I cannot reproduce this in any pre-release prior to pre4 (so I can from pre4 and upwards), I believe this is related to the new packet/fix for https://bugs.mojang.com/browse/MC-156013
See the attached video, reproducing the bug in a freshly created singleplayer world (I also waited for generation to calm down before starting to dig).
Books containing the formatting character '§' make
sthe client mismatch the actual character length, resulting in either one character too much (takes away anothercharacter) or too less (= § or following character still left) being deleted when removing characters.Use the following command to reproduce the issue:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}(This can also be reproduced by having a book with the formatting character in a 1.13 world, and upgrading/opening it with a 1.14+ client.)
What can be observed:
- see attached screenshot: clicking at the end of the line misplaces the cursor a few characters before the click position
- removing '§' characters with the delete key doesn't remove the character setting the color afterward
Books containing the formatting character '§' make the client mismatch the actual character length/text position when clicking the text.
Use the following command to reproduce the issue:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}(This can also be reproduced by having a book with the formatting character in a 1.13 world, and upgrading/opening it with a 1.14+ client.)
What can be observed:
- see attached screenshot: clicking at the end of the line misplaces the cursor a few characters before the click position
- removing '§' characters with the delete key doesn't remove the character setting the color afterward
Books containing the formatting character '§' make the client mismatch the actual character length/text position when clicking the text.
Use the following command to reproduce the issue:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}(This can also be reproduced by having a book with the formatting character in a 1.13 world, and upgrading/opening it with a 1.14+ client.)
What can be observed:
- see attached screenshot: clicking
at the end of the linemisplaces the cursor a few characters before the click position- removing '§' characters with the delete key doesn't remove the character setting the color afterward
Books containing the formatting character '§' make the client mismatch the actual character length/text position when clicking the text.
Use the following command to reproduce the issue:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}(This can also be reproduced by having a book with the formatting character in a 1.13 world, and upgrading/opening it with a 1.14+ client.)
What can be observed:
- see attached screenshot: clicking text after a formatting symbol misplaces the cursor a few characters before the click position
- removing '§' characters with the delete key doesn't remove the character setting the color afterward
Books containing the formatting character '§' make the client mismatch the actual character length/text position when clicking the text.
Use the following command to reproduce the issue:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}(This can also be reproduced by having a book with the formatting character in a 1.13 world, and upgrading/opening it with a 1.14+ client.)
What can be observed:
- see attached screenshot: clicking text after a formatting symbol misplaces the cursor a few characters before the click position
- removing
'§'characters with the delete key doesn't remove the character setting the color afterwardBooks containing the formatting character '§' make the client mismatch the actual character length/text position when clicking the text.
Use the following command to reproduce the issue:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}(This can also be reproduced by having a book with the formatting character in a 1.13 world, and upgrading/opening it with a 1.14+ client.)
What can be observed:
- see attached screenshot: clicking text after a formatting symbol misplaces the cursor a few characters before the click position
- removing the '§' character doesn't remove the character setting the color afterward
- removing the color character doesn't remove the formatting character
Books containing the formatting character '§' make the client mismatch the actual character length/text position when clicking the text.
Use the following command to reproduce the issue:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}(This can also be reproduced by having a book with the formatting character in a 1.13 world, and upgrading/opening
it with a 1.14+ client.)What can be observed:
- see attached screenshot: clicking text after a formatting symbol misplaces the cursor a few characters before the click position
- removing the '§' character doesn't remove the character setting the color afterward
- removing the color character doesn't remove the formatting character
Books containing the formatting character '§' make the client mismatch the actual character length/text position when clicking the text.
Use the following command to reproduce the issue:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}(This can also be reproduced without extra commands by having a book with the formatting character in a 1.13 world by copy-pasting text into it, and upgrading/opening that world with a 1.14+ client.)
What can be observed:
- see attached screenshot: clicking text after a formatting symbol misplaces the cursor a few characters before the click position
- removing the '§' character doesn't remove the character setting the color afterward
- removing the color character doesn't remove the formatting character
Books containing the formatting character '§' make the client mismatch the actual character length/text position when clicking the text.
Use the following command to reproduce the issue:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}(This can also be reproduced without extra commands by having a book with the formatting character in a 1.13 world by copy-pasting text into it, and upgrading/opening that world with a 1.14+ client.)
What can be observed:
- see attached screenshot: clicking text after a formatting symbol misplaces the cursor a few characters before the click position
- removing the '§' character doesn't remove the character setting the color afterward
- removing the color character doesn't remove the formatting character
Books containing the formatting character '§' make the client mismatch the actual character length/text position when clicking the text.
Use the following command to reproduce the issue:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}(This can also be reproduced without extra commands by having a book with the formatting character in a 1.13 world by copy-pasting text into it, and upgrading/opening that world with a 1.14+ client.)
See attached screenshot: clicking text after a formatting symbol misplaces the cursor a few characters before the click position
Books containing the formatting character '§' make the client mismatch the actual character length/text position when clicking the text or moving the cursor using the arrow keys.
Use the following command
toreproduce the issue:/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}(This can also be reproduced without extra commands by having a book with the formatting character in a 1.13 world by copy-pasting text into it, and upgrading/opening that world with a 1.14+ client.)
See attached screenshot: clicking text after a formatting symbol misplaces the cursor a few characters before the click position. Moving the cursor with the arrow keys requires multiple presses to go past the formatting character (see also MC-181673).
Books containing the formatting character '§' make the client mismatch the actual character length/text position when clicking the text or moving the cursor using the arrow keys.
Use the following command and right click the placed sign to get a book and reproduce the issue:
/setblock ~ ~1 ~ minecraft:oak_sign{front_text:{messages:['{"text":"Click me","clickEvent":{"action":"run_command","value":"/give @s minecraft:writable_book[minecraft:writable_book_content={pages:[\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\"]}]"}}', '""', '""', '""']}}
In older versions, the command would be:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}(This can also be reproduced without extra commands by having a book with the formatting character in a 1.13 world by copy-pasting text into it, and upgrading/opening that world with a 1.14+ client.)
See attached screenshot: clicking text after a formatting symbol misplaces the cursor a few characters before the click position. Moving the cursor with the arrow keys requires multiple presses to go past the formatting character (see also MC-181673).
When editing books containing the formatting character '§' followed by a formatting code, only one of them is removed.
Use the following command to reproduce the issue:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}(This can also be reproduced without extra commands by having a book with the formatting character in a 1.13 world by copy-pasting text into it, and upgrading/opening that world with a 1.14+ client.)
What can be observed:
- removing the '§' character doesn't remove the character setting the color afterward (and seemingly makes it pop into existence)
- removing the color character doesn't remove the formatting character (and seemingly makes it pop into existence)
When editing books containing the formatting character '§' followed by a formatting code, only one of them is removed.
Use the following command and right click the placed sign to reproduce the issue:
/setblock ~ ~1 ~ minecraft:oak_sign{front_text:{messages:['{"text":"Click me","clickEvent":{"action":"run_command","value":"/give @s minecraft:writable_book[minecraft:writable_book_content={pages:[\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\"]}]"}}', '""', '""', '""']}}
In older version, it would be:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}
(This can also be reproduced without extra commands by having a book with the formatting character in a 1.13 world by copy-pasting text into it, and upgrading/opening that world with a 1.14+ client.)
What can be observed:
- removing the '§' character doesn't remove the character setting the color afterward (and seemingly makes it pop into existence)
- removing the color character doesn't remove the formatting character (and seemingly makes it pop into existence)
When editing books containing the formatting character '§' followed by a formatting code, only one of them is removed (see in the screenshot, where I pressed delete in the second line and it left he 'r' reset formatting code).
Use the following command and right click the placed sign to reproduce the issue:
/setblock ~ ~1 ~ minecraft:oak_sign{front_text:{messages:['{"text":"Click me","clickEvent":{"action":"run_command","value":"/give @s minecraft:writable_book[minecraft:writable_book_content={pages:[\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\"]}]"}}', '""', '""', '""']}}
In older version, it would be:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}
(This can also be reproduced without extra commands by having a book with the formatting character in a 1.13 world by copy-pasting text into it, and upgrading/opening that world with a 1.14+ client.)
What can be observed:
- removing the '§' character doesn't remove the character setting the color afterward (and seemingly makes it pop into existence)
- removing the color character doesn't remove the formatting character (and seemingly makes it pop into existence)
When editing books containing the formatting character '§' followed by a formatting code, only one of them is removed (see in the screenshot, where I pressed delete in the second line and it left he 'r' reset formatting code).
Use the following command and right click the placed sign to reproduce the issue:
/setblock ~ ~1 ~ minecraft:oak_sign{front_text:{messages:['{"text":"Click me","clickEvent":{"action":"run_command","value":"/give @s minecraft:writable_book[minecraft:writable_book_content={pages:[\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\"]}]"}}', '""', '""', '""']}}
In older version, it would be:
/setblock ~ ~ ~ oak_sign{Text1:"{\"text\":\"Click me\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/give @p writable_book{pages:[\\\"\\u00a7nVery cool text\\n\\u00a7r \\u00a7\\u00a7\\u00a7\\u00a7 hi\\n\\u00a75more\\n\\u00a7etext\\\"]}\"}}"}
(This can also be reproduced without extra commands by having a book with the formatting character in a 1.13 world by copy-pasting text into it, and upgrading/opening that world with a 1.14+ client.)
What can be observed:
- removing the '§' character doesn't remove the character setting the color afterward (and seemingly makes it pop into existence)
- removing the color character doesn't remove the formatting character (and seemingly makes it pop into existence)
The custom sky textures don't work on Pre-3 Vanilla servers
, since the sky effect is took by a map lookup using the dimension data, which doesn't actually implement hashCode or equals checks.
The class 'ClientLevel' gets the effect through:
this.effects = DimensionSpecialEffects.forType(dwm.registryAccess().dimensionTypes().getResourceKey(cha));which used the dimension data sent in Login and Respawn packets to get the dimension key resource location, but this doesn't properly resolve since 'DimensionType' does not implement hashCode or equals (this works on singleplayer due to them just being the same instance).
The custom sky textures don't work on Pre-3 Vanilla servers
The class 'ClientLevel' gets the effect through:
this.effects = DimensionSpecialEffects.forType(dwm.registryAccess().dimensionTypes().getResourceKey(cha));which used the dimension data sent in Login and Respawn packets to get the dimension key resource location, but this doesn't properly resolve since 'DimensionType' does not implement hashCode or equals (this works on singleplayer due to them just being the same instance).
Possible solution: Either send the resource location in Login and Respawn or implement hashCode/equals in DimensionType (the first of which would be preferred for certain modmakers tho)
The custom sky textures don't work on Pre-3 Vanilla servers
The class 'ClientLevel' gets the effect through:
this.effects = DimensionSpecialEffects.forType(dwm.registryAccess().dimensionTypes().getResourceKey(cha));which used the dimension data sent in Login and Respawn packets to get the dimension key resource location, but this doesn't properly resolve since 'DimensionType' does not implement hashCode or equals (this works on singleplayer due to them just being the same instance).
Possible solution: Either send the resource location in Login and Respawn or implement hashCode/equals in DimensionType (the first of which would be preferred for certain modmakers tho)
The custom sky textures don't work on Pre-3 Vanilla servers (servers, not singleplayer!), since the sky effect is took by a map lookup using the dimension data, which doesn't actually implement hashCode or equals checks.
The class 'ClientLevel' gets the effect through:
this.effects = DimensionSpecialEffects.forType(dwm.registryAccess().dimensionTypes().getResourceKey(cha));which used the dimension data sent in Login and Respawn packets to get the dimension key resource location, but this doesn't properly resolve since 'DimensionType' does not implement hashCode or equals (this works on singleplayer due to them just being the same instance).
Possible solution: Either send the resource location in Login and Respawn or implement hashCode/equals in DimensionType (the first of which would be preferred for certain modmakers tho)
The custom sky textures don't work on Pre-3 Vanilla servers (servers, not singleplayer!)
, since the sky effect is took by a map lookup using the dimension data, which doesn't actually implement hashCode or equals checks.
The class 'ClientLevel' gets the effect through:
this.effects = DimensionSpecialEffects.forType(dwm.registryAccess().dimensionTypes().getResourceKey(cha));which used the dimension data sent in Login and Respawn packets to get the dimension key resource location, but this doesn't properly resolve since 'DimensionType' does not implement hashCode or equals (this works on singleplayer due to them just being the same instance).
Possible solution: Either send the resource location in Login and Respawn or implement hashCode/equals in DimensionType (the first of which would be preferred for certain modmakers tho)
The custom sky textures don't work on Pre-3 Vanilla servers (servers, not singleplayer!).
The class 'ClientLevel' gets the effect through:
this.effects = DimensionSpecialEffects.forType(dwm.registryAccess().dimensionTypes().getResourceKey(cha));which used the dimension data sent in Login and Respawn packets to get the dimension key resource location, but this doesn't properly resolve since 'DimensionType' does not implement hashCode or equals (this works on singleplayer due to them just being the same instance).
Possible solution: Either send the resource location in Login and Respawn or implement hashCode/equals in DimensionType (the first of which would be preferred for certain modmakers tho)
Spawning dust/dust transition particles kicks other clients connected to (lan) servers.
The reason for this is the color vectors being written as doubles, but read as floats in DustParticleOptions (in fromNetwork vs. DustParticleOptionsBase#writeToNetwork)
Reproducible by executing this on a server/lan server with another player:
/particle dust 1 0 1 1 ~3 ~1 ~ 1 0 1 1 2000
By placing a boat 5 blocks away from a single water source (in water at level=4), the boat (and thus the player in the boat) can phase through solid blocks below. See the video for where exactly you have to place the boat (with water flowing in the positive x direction, this works by flying at x=.8 of the block and directly looking down for example).
As shown in the second half of the video, this means I can go into an area below the block without destroying it, including bedrock, with only taking half a heart of damage in survival mode.
Code Analysis:
The code-point where the actual phasing happens is in the Boat class in method floatBoat, where in the first if clause this.setPos is called with a y value inside of the block below.
this.setPos(this.getX(), (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D, this.getZ());
Standing at y=64 in the flowing water, the following values were put out:
getWaterLevelAbove() = 64.44444 getBbHeight() = 0.5625 (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D = 63.98294274902344
By placing a boat 5 blocks away from a single water source (in water at level=4), the boat (and thus the player in the boat) can phase through solid blocks below. See the video for where exactly you have to place the boat (with water flowing in the positive x direction, this works by flying at x=.8 of the block and directly looking down for example).
As shown in the second half of the video, this means I can go into an area below the block without destroying it, including bedrock, with only taking half a heart of damage in survival mode.
Code Analysis:
The code-point where the actual phasing happens is in the Boat class in method floatBoat, where in the first if clause this.setPos is called with a y value inside of the block below.
this.setPos(this.getX(), (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D, this.getZ());
Standing at y=64 in the flowing water, the following values were put out:
getWaterLevelAbove() = 64.44444 getBbHeight() = 0.5625 (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D = 63.98294274902344
By placing a boat 5 blocks away from a single water source (in water at level=4), the boat (and thus the player in the boat) can phase through solid blocks below. See the video for where exactly you have to place the boat (with water flowing in the positive x direction, this works by flying at x=.8 of the block and directly looking down for example).
As shown in the second half of the video, this means I can go into an area below the block without destroying it, including bedrock, with only taking half a heart of damage in survival mode.
Code Analysis:
The code-point where the actual phasing happens is in the Boat class in method floatBoat, where in the first if clause this.setPos is called with a y value inside of the block below.
this.setPos(this.getX(), (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D, this.getZ());
Standing at y=64 in the flowing water, the following values were put out:
getWaterLevelAbove() = 64.44444 getBbHeight() = 0.5625 (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D = 63.98294274902344
By placing a boat 5 blocks away from a single water source (in water at level=4), the boat (and thus the player in the boat) can phase through solid blocks below. See the video for where exactly you have to place the boat (with water flowing in the positive x direction, this works by flying at x=.8 of the block and directly looking down for example).
As shown in the second half of the video, this means I can go into an area below the block without destroying it, including bedrock, with only taking half a heart of damage in survival mode.
Code Analysis:
The code-point where the actual phasing happens is in the Boat class in method floatBoat, where in the first if clause this.setPos is called with a y value inside of the block below.
this.setPos(this.getX(), (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D, this.getZ());
Standing at y=64 in the flowing water, the following values were put out:
getWaterLevelAbove() = 64.44444 getBbHeight() = 0.5625 (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D = 63.98294274902344By placing a boat 5 blocks away from a single water source (in water at level=4), the boat (and thus the player in the boat) can phase through solid blocks below. See the video for where exactly you have to place the boat (with water flowing in the positive x direction, this works by flying at x=.8 of the block and directly looking down for example).
As shown in the second half of the video, this means I can go into an area below the block without destroying it, including bedrock, with only taking half a heart of damage in survival mode.
Code Analysis:
The code-point where the actual phasing happens is in the Boat class in method floatBoat, where in the first if clause this.setPos is called with a y value inside of the block below.
this.setPos(this.getX(), (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D, this.getZ());
Standing at y=64 in the flowing water, the following values were put out:
getWaterLevelAbove() = 64.44444 getBbHeight() = 0.5625 (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D = 63.98294274902344
By placing a boat 5 blocks away from a single water source (in water at level=4), the boat (and thus the player in the boat) can phase through solid blocks below. See the video for where exactly you have to place the boat (with
water flowing in the positive x direction, this works by flyingatx=.8 of the block and directly looking downfor example).As shown in the second half of the video, this means I can go into an area below the block without destroying it, including bedrock, with only taking half a heart of damage in survival mode.
Code Analysis:
The code-point where the actual phasing happens is in the Boat class in method floatBoat, where in the first if clause this.setPos is called with a y value inside of the block below.
this.setPos(this.getX(), (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D, this.getZ());
Standing at y=64 in the flowing water, the following values were put out:
getWaterLevelAbove() = 64.44444 getBbHeight() = 0.5625 (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D = 63.98294274902344By placing a boat 5 blocks away from a single water source (in water at level=4), the boat (and thus the player in the boat) can phase through solid blocks below. See the video for where exactly you have to place the boat (with water flowing in the positive x direction, this works by flying at x=.8 of the block and directly looking down for example).
As shown in the second half of the video, this means I can go into an area below the block without destroying it, including bedrock, with only taking half a heart of damage in survival mode.
Code Analysis:
The code-point where the actual phasing happens is in the Boat class in method floatBoat, where in the first if clause this.setPos is called with a y value inside of the block below.
this.setPos(this.getX(), (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D, this.getZ());
Standing at y=64 in the flowing water, the following values were put out:
getWaterLevelAbove() = 64.44444 getBbHeight() = 0.5625 (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D = 63.98294274902344
By placing a boat 5 blocks away from a single water source (in water at level=4), the boat (and thus the player in the boat) can phase through solid blocks below. See the video for where exactly you have to place the boat (with water flowing in the positive x direction, this works by flying at x=.8 of the block and directly looking down for example).
As shown in the second half of the video, this means I can go into an area below the block without destroying it, including bedrock, with only taking half a heart of damage in survival mode.
Sidenote: An easier to way to clip boats into blocks, which only seems to work without passengers, is to just have a boat fall onto flowing water of any level.
Code Analysis:
The code-point where the actual phasing happens is in the Boat class in method floatBoat, where in the first if clause this.setPos is called with a y value inside of the block below.
this.setPos(this.getX(), (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D, this.getZ());
Standing at y=64 in the flowing water, the following values were put out:
getWaterLevelAbove() = 64.44444 getBbHeight() = 0.5625 (double) (this.getWaterLevelAbove() - this.getBbHeight()) + 0.101D = 63.98294274902344
World loadingscreen is hardcoded to be open for at least 2 secondsWorld loading cannot close before 2 seconds have passed
World loadingcannot close before 2 seconds have passedLoading terrain screen cannot close before 2 seconds have passed
When joining a server or changing worlds, the loading terrain screen will be no shorter than 2 seconds as per the first condition in the ReceivingLevelScreen tick, even if the world is already loaded with chunks sent and rendered.
public void tick() { boolean var0 = this.oneTickSkipped || System.currentTimeMillis() > this.createdAt + 2000L; if (var0 && this.minecraft != null && this.minecraft.player != null) { // ... if (current chunk rendered) { this.onClose(); } if (has received setdefaultspawnpacket) { this.oneTickSkipped = true; } }with no other place where the oneTickSkipped field is set, so the onClose call is only reached if at least 2 seconds have passed since opening the screen.
Just ripping the check out brings back visually falling throuhg the ground for a bit on Vanilla servers, but imo just hard waiting 2 seconds is a rather disruptive way of just hiding the problem.
The underlying problem seems to be the client predictavely starting to fall before anything has been sent (and the server only starts ticking an actual fall when the client is at the proper position again).
When joining a server or changing worlds, the loading terrain screen will be no shorter than 2 seconds as per the first condition in the ReceivingLevelScreen tick, even if the world is already loaded with chunks sent and rendered.
public void tick() { boolean var0 = this.oneTickSkipped || System.currentTimeMillis() > this.createdAt + 2000L; if (var0 && this.minecraft != null && this.minecraft.player != null) { // ... if (current chunk rendered) { this.onClose(); } if (has received setdefaultspawnpacket) { this.oneTickSkipped = true; } }with no other place where the oneTickSkipped field is set, so the onClose call is only reached if at least 2 seconds have passed since opening the screen.
Just ripping the check out brings back visually falling throuhg the ground for a bit on Vanilla servers, but imo just hard waiting 2 seconds is a rather disruptive way of just hiding the problem.
The underlying problem seems to be the client predictavely starting to fall before anything has been sent (and the server only starts ticking an actual fall when the client is at the proper position again).
When joining a server or changing worlds, the loading terrain screen will be no shorter than 2 seconds as per the first condition in the ReceivingLevelScreen tick, even if the world is already loaded with chunks sent and rendered.
public void tick() { boolean var0 = this.oneTickSkipped || System.currentTimeMillis() > this.createdAt + 2000L; if (var0 && this.minecraft != null && this.minecraft.player != null) { // ... if (current chunk rendered) { this.onClose(); } if (has received setdefaultspawnpacket) { this.oneTickSkipped = true; } }with no other place where the oneTickSkipped field is set, so the onClose call is only reached if at least 2 seconds have passed since opening the screen.
Just ripping the check out brings back visually falling throuhg the ground for a bit on Vanilla servers on world changing (not joining), but imo just hard waiting 2 seconds is a rather disruptive way of hiding the problem.
The underlying problem seems to be the client predictavely starting to fall before anything has been sent (and the server only starts ticking an actual fall when the client is at the proper position again).
When joining a server or changing worlds, the loading terrain screen will be no shorter than 2 seconds as per the first condition in the ReceivingLevelScreen tick, even if the world is already loaded with chunks sent and rendered.
public void tick() { boolean var0 = this.oneTickSkipped || System.currentTimeMillis() > this.createdAt + 2000L; if (var0 && this.minecraft != null && this.minecraft.player != null) { // ... if (current chunk rendered) { this.onClose(); } if (has received setdefaultspawnpacket) { this.oneTickSkipped = true; } }with no other place where the oneTickSkipped field is set, so the onClose call is only reached if at least 2 seconds have passed since opening the screen.
Just ripping the check out brings back visually falling throuhg the ground for a bit on Vanilla servers on world changing (not joining), but imo just hard waiting 2 seconds is a rather disruptive way of hiding the problem.
The underlying problem seems to be the client predictavely starting to fall before anything has been sent (andthe server only starts ticking an actual fallwhenthe client is at the proper position again).When joining a server or changing worlds, the loading terrain screen will be no shorter than 2 seconds as per the first condition in the ReceivingLevelScreen tick, even if the world is already loaded with chunks sent and rendered.
public void tick() { boolean var0 = this.oneTickSkipped || System.currentTimeMillis() > this.createdAt + 2000L; if (var0 && this.minecraft != null && this.minecraft.player != null) { // ... if (current chunk rendered) { this.onClose(); } if (has received setdefaultspawnpacket) { this.oneTickSkipped = true; } }with no other place where the oneTickSkipped field is set, so the onClose call is only reached if at least 2 seconds have passed since opening the screen.
Just ripping the check out brings back visually falling throuhg the ground for a bit on Vanilla servers on world changing (not joining), but imo just hard waiting 2 seconds is a rather disruptive way of hiding the problem.
The underlying problem seems to be the client predictavely starting to fall before receiving chunk data (the server only starts ticking an actual fall and puts the client is at the proper position again).
When joining a server or changing worlds, the loading terrain screen will be no shorter than 2 seconds as per the first condition in the ReceivingLevelScreen tick, even if the world is already loaded with chunks sent and rendered.
public void tick() { boolean var0 = this.oneTickSkipped || System.currentTimeMillis() > this.createdAt + 2000L; if (var0 && this.minecraft != null && this.minecraft.player != null) { // ... if (current chunk rendered) { this.onClose(); } if (has received setdefaultspawnpacket) { this.oneTickSkipped = true; } }with no other place where the oneTickSkipped field is set, so the onClose call is only reached if at least 2 seconds have passed since opening the screen.
Just ripping the check out brings back visually falling throuhg the ground for a bit on Vanilla servers on world changing (not joining), but imo just hard waiting 2 seconds is a rather disruptive way of hiding the problem.
The underlying problem seems to be the client predictavely starting to fall before receiving chunk data (the server only starts ticking an actual fall and puts the client is at the proper position again).When joining a server or changing worlds, the loading terrain screen will be no shorter than 2 seconds as per the first condition in the ReceivingLevelScreen tick, even if the world is already loaded with chunks sent and rendered.
public void tick() { boolean var0 = this.oneTickSkipped || System.currentTimeMillis() > this.createdAt + 2000L; if (var0 && this.minecraft != null && this.minecraft.player != null) { // ... if (current chunk rendered) { this.onClose(); } if (has received setdefaultspawnpacket) { this.oneTickSkipped = true; } }with no other place where the oneTickSkipped field is set, so the onClose call is only reached if at least 2 seconds have passed since opening the screen.
Just ripping the check out brings back visually falling throuhg the ground for a bit on Vanilla servers on world changing (not joining), but imo just hard waiting 2 seconds is a rather disruptive way of hiding the problem.
The underlying problem seems to be the client predictively starting to fall before receiving chunk data (the server only starts ticking an actual fall and puts the client is at the proper position again).
When joining a server or changing worlds, the loading terrain screen will be no shorter than 2 seconds as per the first condition in the ReceivingLevelScreen tick, even if the world is already loaded with chunks sent and rendered.
public void tick() { boolean var0 = this.oneTickSkipped || System.currentTimeMillis() > this.createdAt + 2000L; if (var0 && this.minecraft != null && this.minecraft.player != null) { // ... if (current chunk rendered) { this.onClose(); } if (has received setdefaultspawnpacket) { this.oneTickSkipped = true; } }with no other place where the oneTickSkipped field is set, so the onClose call is only reached if at least 2 seconds have passed since opening the screen.
Just ripping the check out brings back visuallyfalling throuhg the groundfor a biton Vanilla servers onworldchanging (not joining), but imo just hard waiting 2 seconds is a rather disruptive way of hiding the problem.
The underlying problem seems to be the client predictively starting to fall before receiving chunk data (the server only starts ticking an actual fall and puts the client is at the proper position again).When joining a server or changing worlds, the loading terrain screen will be no shorter than 2 seconds as per the first condition in the ReceivingLevelScreen tick, even if the world is already loaded with chunks sent and rendered.
public void tick() { boolean var0 = this.oneTickSkipped || System.currentTimeMillis() > this.createdAt + 2000L; if (var0 && this.minecraft != null && this.minecraft.player != null) { // ... if (current chunk rendered) { this.onClose(); } if (has received setdefaultspawnpacket) { this.oneTickSkipped = true; } }with no other place where the oneTickSkipped field is set, so the onClose call is only reached if at least 2 seconds have passed since opening the screen.
Just ripping the check out brings back visually falling through the ground on Vanilla servers on changing dimensions (not joining), but imo just hard waiting 2 seconds is a rather disruptive way of hiding the problem.
The underlying problem seems to be the client predictively starting to fall before receiving chunk data (the server only starts ticking an actual fall and puts the client is at the proper position again).
When joining a server or changing
worlds, the loading terrain screen will be no shorter than 2 seconds as per the first condition in the ReceivingLevelScreen tick, even if the world is already loaded with chunks sent and rendered.public void tick() { boolean var0 = this.oneTickSkipped || System.currentTimeMillis() > this.createdAt + 2000L; if (var0 && this.minecraft != null && this.minecraft.player != null) { // ... if (current chunk rendered) { this.onClose(); } if (has received setdefaultspawnpacket) { this.oneTickSkipped = true; } }with no other place where the oneTickSkipped field is set, so the onClose call is only reached if at least 2 seconds have passed since opening the screen.
Just ripping the check out brings back visually falling through the ground on Vanilla servers on changing dimensions (not joining), but imo just hard waiting 2 seconds is a rather disruptive way of hiding the problem.
The underlying problem seems to be the client predictively starting to fall before receiving chunk data (the server only starts ticking an actual fall and puts the client is at the proper position again).When joining a server or changing dimensions, the loading terrain screen will be no shorter than 2 seconds as per the first condition in the ReceivingLevelScreen tick, even if the world is already loaded with chunks sent and rendered.
public void tick() { boolean var0 = this.oneTickSkipped || System.currentTimeMillis() > this.createdAt + 2000L; if (var0 && this.minecraft != null && this.minecraft.player != null) { // ... if (current chunk rendered) { this.onClose(); } if (has received setdefaultspawnpacket) { this.oneTickSkipped = true; } }with no other place where the oneTickSkipped field is set, so the onClose call is only reached if at least 2 seconds have passed since opening the screen.
Just ripping the check out brings back visually falling through the ground on Vanilla servers on changing dimensions (not joining), but imo just hard waiting 2 seconds is a rather disruptive way of hiding the problem.
The underlying problem seems to be the client predictively starting to fall before receiving chunk data (the server only starts ticking an actual fall and puts the client is at the proper position again).
When joining a server or changing dimensions, the loading terrain screen will be no shorter than 2 seconds as per the first condition in the ReceivingLevelScreen tick, even if the world is already loaded with chunks sent and rendered.
public void tick() { boolean var0 = this.oneTickSkipped || System.currentTimeMillis() > this.createdAt + 2000L; if (var0 && this.minecraft != null && this.minecraft.player != null) { // ... if (current chunk rendered) { this.onClose(); } if (has received setdefaultspawnpacket) { this.oneTickSkipped = true; } }with no other place where the oneTickSkipped field is set, so the onClose call is only reached if at least 2 seconds have passed since opening the screen.
Just ripping the check out brings back visually falling through the ground on Vanilla servers on changing dimensions (not joining), but imo just hard waiting 2 seconds is a rather disruptive way of hiding the problem.
The underlying problem seems to be the client predictively starting to fall before receiving chunk data (the serveronlystarts ticking an actual fall and puts the clientisat the proper position again).When joining a server or changing dimensions, the loading terrain screen will be no shorter than 2 seconds as per the first condition in the ReceivingLevelScreen tick, even if the world is already loaded with chunks sent and the one the client is in rendered.
public void tick() { boolean var0 = this.oneTickSkipped || System.currentTimeMillis() > this.createdAt + 2000L; if (var0 && this.minecraft != null && this.minecraft.player != null) { // ... if (current chunk rendered) { this.onClose(); } if (has received setdefaultspawnpacket) { this.oneTickSkipped = true; } }with no other place where the oneTickSkipped field is set, so the onClose call is only reached if at least 2 seconds have passed since opening the screen.
Just ripping the check out brings back visually falling through the ground on Vanilla servers on changing dimensions (not joining?), but imo just hard waiting 2 seconds is a rather disruptive way of hiding the problem.
The underlying problem of that one seems to be the client predictively starting to fall before receiving chunk data (only after that the server starts ticking an actual fall and puts the client at the proper position again).
When joining a server or changing dimensions, the loading terrain screen will be no shorter than 2 seconds as per the first condition in the ReceivingLevelScreen tick, even if the world is already loaded with chunks sent and the one the client is in rendered.
public void tick() { boolean var0 = this.oneTickSkipped || System.currentTimeMillis() > this.createdAt + 2000L; if (var0 && this.minecraft != null && this.minecraft.player != null) { // ... if (current chunk rendered) { this.onClose(); } if (has received setdefaultspawnpacket) { this.oneTickSkipped = true; } }with no other place where the oneTickSkipped field is set, so the onClose call is only reached if at least 2 seconds have passed since opening the screen.
Just ripping the check out brings back visually falling through the ground on Vanilla servers on changing dimensions (not joining?), but imo just hard waiting 2 seconds is a rather disruptive way of hiding the problem.
The underlying problem of that one seems to be the client predictively starting to fall before receiving chunk data while the loading screen is still open (only after that the server starts ticking an actual fall and puts the client at the proper position again).
Placing paintings that span over 2 or 4 blocks makes them display off-centered when on a multiplayer/local-lan server (see attached screenshot
- it's from 22w16a, but the same applies to the b snapshot).Placing paintings that span over 2 or 4 blocks makes them display off-centered when on a multiplayer/local-lan server (see attached screenshots).
When a player does not send the profile public key on login in ServerboundHelloPacket, messages of that player will not have any special mark to tell other players that the message cannot be validated (no matter if it is a valid signature or not).
The local lan host is a Vanilla client, the other a modified client (ignoring that it's 1.18.2; that's just network level transformation that then sends the empty optional key and bogus signatures). 0x55 is the player sending messages with invalid signatures
When a player does not send the profile public key on login in ServerboundHelloPacket, messages of that player will not have any special mark to tell other players that the message cannot be validated (no matter if it is a valid signature or not).
The info below is just how I encountered it and to have a hint at what I'm describing, the setup there is not fully relevant to the issue.
The local lan host is a Vanilla client, the other a modified client (ignoring that it's 1.18.2; that's just network level transformation that then sends the empty optional key and bogus signatures). 0x55 is the player sending messages with invalid signatures. As you can see on the left, messages by 0x55 have no special indicator (as opposed to messages with invalid signatures of players that did send the profile key; see other attachment)
When a player does not send the profile public key on login in ServerboundHelloPacket, messages of that player will not have any special mark to tell other players that the message cannot be validated (no matter if it is a valid signature or not). These messages will also still be shown when you have the "Only Show Secure Chat" option enabled.
The info below is just how I encountered it and to have a hint at what I'm describing, the setup there is not fully relevant to the issue.
The local lan host is a Vanilla client, the other a modified client (ignoring that it's 1.18.2; that's just network level transformation that then sends the empty optional key and bogus signatures). 0x55 is the player sending messages with invalid signatures. As you can see on the left, messages by 0x55 have no special indicator (as opposed to messages with invalid signatures of players that did send the profile key; see other attachment)
When a player does not send the profile public key on login in ServerboundHelloPacket, messages of that player will not have any special mark to tell other players that the message cannot be validated (no matter if it is a valid signature or not). These messages will also still be shown when you have the "Only Show Secure Chat" option enabled.
The info below is just how I encountered it and to have a hint at what I'm describing, the setup there is not fully relevant to the issue.
The local lan host is a Vanilla client, the other a modified client (ignoring that it's 1.18.2; that's just network level transformation that then sends the empty optional key and bogus signatures). 0x55 is the player sending messages with invalid signatures. As you can see on the left, messages by 0x55 have no special indicator (as opposed to messages with invalid signatures of players that did send the profile key; see other attachment)
When a player does not send the profile public key on login in ServerboundHelloPacket , messages of that player will not have any special mark to tell other players that the message cannot be validated (no matter if it is a valid signature or not). These messages will also still be shown when you have the "Only Show Secure Chat" option enabled.
When a player does not send the profile public key on login in ServerboundHelloPacket , messages of that player will not have any special mark to tell other players that the message cannot be validated (no matter if it is a valid signature or not). These messages will also still be shown when you have the "Only Show Secure Chat" option enabled.Nevermind, local lan players always have everything show as secure, which looks like it's intended.
Setting the bundlerMainClass property to net.minecraft.data.Main and starting the bundler with the --reports option crashes with the following error:
[17:11:36] [ServerMain/INFO]: Building unoptimized datafixer [17:11:37] [ServerMain/INFO]: Starting provider: vanilla/Biome Parameters Exception in thread "ServerMain" [17:11:37] [ServerMain/INFO]: [STDERR]: java.util.concurrent.CompletionException: java.lang.IllegalStateException: Missing element ResourceKey[minecraft:worldgen/biome / minecraft:cherry_grove] [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1159) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1760) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) [17:11:37] [ServerMain/INFO]: [STDERR]: Caused by: java.lang.IllegalStateException: Missing element ResourceKey[minecraft:worldgen/biome / minecraft:cherry_grove] [17:11:37] [ServerMain/INFO]: [STDERR]: at hc.c(SourceFile:15) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.Optional.orElseThrow(Optional.java:403) [17:11:37] [ServerMain/INFO]: [STDERR]: at hc.b(SourceFile:15) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:147) [17:11:37] [ServerMain/INFO]: [STDERR]: at com.mojang.datafixers.util.Pair.mapSecond(Pair.java:68) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:142) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.a(SourceFile:599) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.c(SourceFile:393) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.d(SourceFile:272) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.a(SourceFile:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:142) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a$3.apply(SourceFile:122) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:147) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:152) [17:11:37] [ServerMain/INFO]: [STDERR]: at jv.a(SourceFile:42) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.HashMap$EntrySpliterator.forEachRemaining(HashMap.java:1850) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) [17:11:37] [ServerMain/INFO]: [STDERR]: at jv.a(SourceFile:45) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150) [17:11:37] [ServerMain/INFO]: [STDERR]: ... 8 moreSetting the bundlerMainClass property to net.minecraft.data.Main and starting the bundler with the --reports option crashes with the following error:
[17:11:36] [ServerMain/INFO]: Building unoptimized datafixer [17:11:37] [ServerMain/INFO]: Starting provider: vanilla/Biome Parameters Exception in thread "ServerMain" [17:11:37] [ServerMain/INFO]: [STDERR]: java.util.concurrent.CompletionException: java.lang.IllegalStateException: Missing element ResourceKey[minecraft:worldgen/biome / minecraft:cherry_grove] [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1159) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1760) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) [17:11:37] [ServerMain/INFO]: [STDERR]: Caused by: java.lang.IllegalStateException: Missing element ResourceKey[minecraft:worldgen/biome / minecraft:cherry_grove] [17:11:37] [ServerMain/INFO]: [STDERR]: at hc.c(SourceFile:15) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.Optional.orElseThrow(Optional.java:403) [17:11:37] [ServerMain/INFO]: [STDERR]: at hc.b(SourceFile:15) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:147) [17:11:37] [ServerMain/INFO]: [STDERR]: at com.mojang.datafixers.util.Pair.mapSecond(Pair.java:68) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:142) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.a(SourceFile:599) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.c(SourceFile:393) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.d(SourceFile:272) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.a(SourceFile:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:142) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a$3.apply(SourceFile:122) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:147) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:152) [17:11:37] [ServerMain/INFO]: [STDERR]: at jv.a(SourceFile:42) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.HashMap$EntrySpliterator.forEachRemaining(HashMap.java:1850) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) [17:11:37] [ServerMain/INFO]: [STDERR]: at jv.a(SourceFile:45) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150) [17:11:37] [ServerMain/INFO]: [STDERR]: ... 8 more
Setting the bundlerMainClass property to net.minecraft.data.Main and starting the server bundler jar with the --reports option crashes with the following error:
[17:11:36] [ServerMain/INFO]: Building unoptimized datafixer [17:11:37] [ServerMain/INFO]: Starting provider: vanilla/Biome Parameters Exception in thread "ServerMain" [17:11:37] [ServerMain/INFO]: [STDERR]: java.util.concurrent.CompletionException: java.lang.IllegalStateException: Missing element ResourceKey[minecraft:worldgen/biome / minecraft:cherry_grove] [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1159) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1760) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) [17:11:37] [ServerMain/INFO]: [STDERR]: Caused by: java.lang.IllegalStateException: Missing element ResourceKey[minecraft:worldgen/biome / minecraft:cherry_grove] [17:11:37] [ServerMain/INFO]: [STDERR]: at hc.c(SourceFile:15) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.Optional.orElseThrow(Optional.java:403) [17:11:37] [ServerMain/INFO]: [STDERR]: at hc.b(SourceFile:15) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:147) [17:11:37] [ServerMain/INFO]: [STDERR]: at com.mojang.datafixers.util.Pair.mapSecond(Pair.java:68) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:142) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.a(SourceFile:599) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.c(SourceFile:393) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.d(SourceFile:272) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.a(SourceFile:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:142) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a$3.apply(SourceFile:122) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:147) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:152) [17:11:37] [ServerMain/INFO]: [STDERR]: at jv.a(SourceFile:42) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.HashMap$EntrySpliterator.forEachRemaining(HashMap.java:1850) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) [17:11:37] [ServerMain/INFO]: [STDERR]: at jv.a(SourceFile:45) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150) [17:11:37] [ServerMain/INFO]: [STDERR]: ... 8 more
Setting the "bundlerMainClass" system property to "net.minecraft.data.Main" and starting the server bundler jar with the "--reports" option crashes with the following error:
[17:11:36] [ServerMain/INFO]: Building unoptimized datafixer [17:11:37] [ServerMain/INFO]: Starting provider: vanilla/Biome Parameters Exception in thread "ServerMain" [17:11:37] [ServerMain/INFO]: [STDERR]: java.util.concurrent.CompletionException: java.lang.IllegalStateException: Missing element ResourceKey[minecraft:worldgen/biome / minecraft:cherry_grove] [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1159) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1760) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) [17:11:37] [ServerMain/INFO]: [STDERR]: Caused by: java.lang.IllegalStateException: Missing element ResourceKey[minecraft:worldgen/biome / minecraft:cherry_grove] [17:11:37] [ServerMain/INFO]: [STDERR]: at hc.c(SourceFile:15) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.Optional.orElseThrow(Optional.java:403) [17:11:37] [ServerMain/INFO]: [STDERR]: at hc.b(SourceFile:15) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:147) [17:11:37] [ServerMain/INFO]: [STDERR]: at com.mojang.datafixers.util.Pair.mapSecond(Pair.java:68) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:142) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.a(SourceFile:599) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.c(SourceFile:393) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.d(SourceFile:272) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.a(SourceFile:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:142) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a$3.apply(SourceFile:122) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:147) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:152) [17:11:37] [ServerMain/INFO]: [STDERR]: at jv.a(SourceFile:42) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.HashMap$EntrySpliterator.forEachRemaining(HashMap.java:1850) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) [17:11:37] [ServerMain/INFO]: [STDERR]: at jv.a(SourceFile:45) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150) [17:11:37] [ServerMain/INFO]: [STDERR]: ... 8 more
Setting the "bundlerMainClass" system property to "net.minecraft.data.Main" and starting the server bundler jar (with or without the "--reports" option) crashes with the following error:
[17:11:36] [ServerMain/INFO]: Building unoptimized datafixer [17:11:37] [ServerMain/INFO]: Starting provider: vanilla/Biome Parameters Exception in thread "ServerMain" [17:11:37] [ServerMain/INFO]: [STDERR]: java.util.concurrent.CompletionException: java.lang.IllegalStateException: Missing element ResourceKey[minecraft:worldgen/biome / minecraft:cherry_grove] [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1159) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1760) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) [17:11:37] [ServerMain/INFO]: [STDERR]: Caused by: java.lang.IllegalStateException: Missing element ResourceKey[minecraft:worldgen/biome / minecraft:cherry_grove] [17:11:37] [ServerMain/INFO]: [STDERR]: at hc.c(SourceFile:15) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.Optional.orElseThrow(Optional.java:403) [17:11:37] [ServerMain/INFO]: [STDERR]: at hc.b(SourceFile:15) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:147) [17:11:37] [ServerMain/INFO]: [STDERR]: at com.mojang.datafixers.util.Pair.mapSecond(Pair.java:68) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:142) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.a(SourceFile:599) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.c(SourceFile:393) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.d(SourceFile:272) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.a(SourceFile:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:142) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a$3.apply(SourceFile:122) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:147) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:152) [17:11:37] [ServerMain/INFO]: [STDERR]: at jv.a(SourceFile:42) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.HashMap$EntrySpliterator.forEachRemaining(HashMap.java:1850) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) [17:11:37] [ServerMain/INFO]: [STDERR]: at jv.a(SourceFile:45) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150) [17:11:37] [ServerMain/INFO]: [STDERR]: ... 8 more
Starting data.Mainwith --reports option crashesStarting data.Main for data generation crashes
Setting the "bundlerMainClass" system property to "net.minecraft.data.Main" and starting the server bundler jar
(with or without the "--reports" option)crashes with the following error:[17:11:36] [ServerMain/INFO]: Building unoptimized datafixer [17:11:37] [ServerMain/INFO]: Starting provider: vanilla/Biome Parameters Exception in thread "ServerMain" [17:11:37] [ServerMain/INFO]: [STDERR]: java.util.concurrent.CompletionException: java.lang.IllegalStateException: Missing element ResourceKey[minecraft:worldgen/biome / minecraft:cherry_grove] [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1159) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1760) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) [17:11:37] [ServerMain/INFO]: [STDERR]: Caused by: java.lang.IllegalStateException: Missing element ResourceKey[minecraft:worldgen/biome / minecraft:cherry_grove] [17:11:37] [ServerMain/INFO]: [STDERR]: at hc.c(SourceFile:15) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.Optional.orElseThrow(Optional.java:403) [17:11:37] [ServerMain/INFO]: [STDERR]: at hc.b(SourceFile:15) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:147) [17:11:37] [ServerMain/INFO]: [STDERR]: at com.mojang.datafixers.util.Pair.mapSecond(Pair.java:68) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:142) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.a(SourceFile:599) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.c(SourceFile:393) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.d(SourceFile:272) [17:11:37] [ServerMain/INFO]: [STDERR]: at cns.a(SourceFile:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:142) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a$3.apply(SourceFile:122) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:147) [17:11:37] [ServerMain/INFO]: [STDERR]: at cnr$a.a(SourceFile:152) [17:11:37] [ServerMain/INFO]: [STDERR]: at jv.a(SourceFile:42) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.HashMap$EntrySpliterator.forEachRemaining(HashMap.java:1850) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) [17:11:37] [ServerMain/INFO]: [STDERR]: at jv.a(SourceFile:45) [17:11:37] [ServerMain/INFO]: [STDERR]: at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150) [17:11:37] [ServerMain/INFO]: [STDERR]: ... 8 more
Can't remove book from chiseled bookshelf, record from jukebox with /item command
How to reproduce:
- Place a chiseled bookshelf
- add a book to the first slot (top left)
- standing on top of the block, execute
/item replace block ~ ~-1 ~ container.0 with air-> the book will not be removed
Removing an item like this works for every single other block entity container in the game.
Possible fix: Update the if clause in the setItem method in ChiseledBookShelfBlockEntity to allow empty items
How to reproduce:
- Place a chiseled bookshelf
- add a book to the first slot (top left)
- standing on top of the block, execute
/item replace block ~ ~-1 ~ container.0 with air-> the book will not be removed
Removing an item like this works for every single other block entity container in the game (except for jukeboxes, also being affected by this since being made a container entity).
Possible fix: Update the if clause in the setItem method in ChiseledBookShelfBlockEntity to allow empty items
How to reproduce:
- Place a chiseled bookshelf
- add a book to the first slot (top left)
- standing on top of the block, execute
/item replace block ~ ~-1 ~ container.0 with air-> the book will not be removed
Removing an item like this works for every single other block entity container in the game (except for jukeboxes, also being affected by this since being made a container block entity).
Possible fix: Update the if clause in the setItem method in ChiseledBookShelfBlockEntity to allow empty items
When the server kicks the player for an invalid signature, outdated client, or whatever else during the login phase, the player will see something like th
isinstead of the disconnect messageThis is due to ClientboundLoginDisconnectPacket reading the compound as a json string but writing nbt
When the server kicks the player for an invalid signature, outdated client, or whatever else during the login phase, the player will see something like the attached image instead of the disconnect message
This is due to ClientboundLoginDisconnectPacket reading the compound as a json string but writing nbt
When the server kicks the player for an invalid signature, outdated client, or whatever else during the login phase, the player will see something like the attached image instead of the disconnect message
This is due to ClientboundLoginDisconnectPacket reading the compo
undas a json string but writing nbtWhen the server kicks the player for an invalid signature, outdated client, or whatever else during the login phase, the player will see something like the attached image instead of the disconnect message
This is due to ClientboundLoginDisconnectPacket reading the component as a json string but writing nbt
When the server kicks the player for an invalid
signature, outdated client, or whatever else during the login phase, the player will see something like the attached image instead of the disconnect messageThis is due to ClientboundLoginDisconnectPacket reading the component as a json string but writing nbt
When the server kicks the player for an invalid profile key, outdated client, or whatever else during the login phase, the player will see something like the attached image instead of the disconnect message
This is due to ClientboundLoginDisconnectPacket reading the component as a json string but writing nbt
When the server kicks the player for an invalid profile key, outdated client, or whatever else during the login phase, the player will see something like the attached image instead of the actual disconnect message
This is due to ClientboundLoginDisconnectPacket reading the component as a json string but writing nbt
When the server kicks the player for an invalid profile key, outdated client, or whatever else during the login phase, the player will see something like the attached image instead of the actual disconnect message
This is due to ClientboundLoginDisconnectPacket reading the component as a json string, but writing nbt
I don't think this is working as intended. It not being turned into a string is fine, but this is turning a boolean into a number
is duplicated by
duplicates
is duplicated by
Spawned item entities from a mobs loot table may not save their "Item" tag resulting in the item entities getting killed immediately after they have spawned. I have noticed this happening with the loot command. I don't know if the same applies to a natural scenario.
Reproduce:
- Spawn in any mob whose loot table can drop items (e.g. creeper)
- Setup a command block chain:
- Impulse
Set to: "Needs Redstone"- Chain
Set to: "Always Active"
Command:loot spawn <pos> kill <the mob entity>- Chain
Set to: "Always Active"
Command:execute as @e[type=item] unless data entity @s Item run say hiMake sure the @e selector won't catch any other existing entities.
- Activate the impulse command block (probably multiple times)
You may notice the "Item" tag sometimes being omitted in the chat message.
Spawned item entities from a mobs loot table may not save their "Item" tag resulting in the item entities getting killed immediately after they have spawned. I have noticed this happening with the loot command. I don't know if the same applies to a natural scenario.
Reproduce:
- Spawn in any mob whose loot table can drop items (e.g. creeper)
- Setup a command block chain:
- Impulse
Set to: "Needs Redstone"- Chain
Set to: "Always Active"
Command:loot spawn <pos> kill <the mob entity>e.g. after placing a witch near the command block:
loot spawn ~ ~1 ~ kill @e[type=witch,distance=..5,limit=1]
- Chain
Set to: "Always Active"
Command:execute as @e[type=item] unless data entity @s Item run say hiMake sure the @e selector won't catch any other existing entities.
- Activate the impulse command block (probably multiple times)
You may notice the "Item" tag sometimes being omitted in the chat message.
There are severe performance issues when transmitting item_displays.Fast/long command block output can result in lag
"Please forgive me for using a non-English languageto provide feedback on the issue previously, but I am confident that the issue remains unresolved."
Original: In the Minecraft version 1.21.1, upon employing two perpetually active loop command blocks, each executing the following commands:1. execute at @e[type=minecraft:snowball] run summon minecraft:item_display ~ ~ ~ {item:{id:'minecraft:diamond'}}
2. execute as @e[type=minecraft:item_display] at @s run tp @s ~ ~ ~ facing entity %YOUR_NAME%
（Note: you need to replace %YOUR_NAME% to your minecraft name）
When a snowball is thrown, the game unexpectedly halts, posing a significant hindrance to gameplay continuation.
It seems that this issue is more likely to occur on computers with lower configurations. If your computer is as good as my new one, you might need to throw several snowballs to reproduce the problem.
After multiple tests, it seems that the performance issue is more severe when using item_displays, and this issue only arises during teleportation (tp).
Steps to Reproduce:
1. Position a loop command block and configure it to be always active.
2. Input the first command: execute at @e[type=minecraft:snowball] run summon minecraft:item_display ~ ~ ~ {item:{id:'minecraft:diamond'},item_display:{gui:true}}
3. Place another loop command block and similarly configure it for perpetual activation.
4. Enter the second command: execute as @e[type=minecraft:item_display] at @s run tp @s ~ ~ ~ facing entity %YOUR_NAME%
- Remember to substitute `%YOUR_NAME%` with your actual Minecraft username.
5. Throw a snowball.
(If your computer is as good as my new one, you might need to throw several snowballs to reproduce the problem.)
6. Observe the immediate freezing of the game.
Expected Outcome:
The `item_display` entities should seamlessly teleport without any disruption to the game's flow, ensuring a smooth playing experience.
Upon employing two perpetually active loop command blocks, each executing the following commands:
1. execute at @e[type=minecraft:snowball] run summon minecraft:item_display ~ ~ ~ {item:{id:'minecraft:diamond'}}
2. execute as @e[type=minecraft:item_display] at @s run tp @s ~ ~ ~ facing entity %YOUR_NAME%
（Note: you need to replace %YOUR_NAME% to your minecraft name）
When a snowball is thrown, the game unexpectedly halts, posing a significant hindrance to gameplay continuation. This seems to stem from the large amounts of log messages produced from the command blocks.
It seems that this issue is more likely to occur on computers with lower configurations. If your computer is as good as my new one, you might need to throw several snowballs to reproduce the problem.
After multiple tests, it seems that the performance issue is more severe when using item_displays, and this issue only arises during teleportation (tp).
Steps to Reproduce:
1. Position a loop command block and configure it to be always active.
2. Input the first command: execute at @e[type=minecraft:snowball] run summon minecraft:item_display ~ ~ ~ {item:{id:'minecraft:diamond'},item_display:{gui:true}}
3. Place another loop command block and similarly configure it for perpetual activation.
4. Enter the second command: execute as @e[type=minecraft:item_display] at @s run tp @s ~ ~ ~ facing entity %YOUR_NAME%
- Remember to substitute `%YOUR_NAME%` with your actual Minecraft username.
5. Throw a snowball.
(If your computer is as good as my new one, you might need to throw several snowballs to reproduce the problem.)
6. Observe the immediate freezing of the game.
Expected Outcome:
The `item_display` entities should seamlessly teleport without any disruption to the game's flow, ensuring a smooth playing experience.
Upon employing two perpetually active loop command blocks, each executing the following commands:
1. execute at @e[type=minecraft:snowball] run summon minecraft:item_display ~ ~ ~ {item:{id:'minecraft:diamond'}}
2. execute as @e[type=minecraft:item_display] at @s run tp @s ~ ~ ~ facing entity %YOUR_NAME%
（Note: you need to replace %YOUR_NAME% to your minecraft name）
When a snowball is thrown, the game unexpectedly halts, posing a significant hindrance to gameplay continuation. This seems to stem from the large amounts of log messages produced from the command blocks.It seems that this issue is more likely to occur on computers with lower configurations. If your computer is as good as my new one, you might need to throw several snowballs to reproduce the problem.
After multiple tests, it seems that the performance issue is more severe when using item_displays, and this issue only arises during teleportation (tp).
Steps to Reproduce:
1. Position a loop command block and configure it to be always active.
2. Input the first command: execute at @e[type=minecraft:snowball] run summon minecraft:item_display ~ ~ ~ {item:{id:'minecraft:diamond'},item_display:{gui:true}}
3. Place another loop command block and
similarly configure it for perpetual activation.4. Enter the second command: execute as @e[type=minecraft:item_display] at @s run tp @s ~ ~ ~ facing entity %YOUR_NAME%
- Remember to substitute `%YOUR_NAME%` with your actual Minecraft username.
5. Throw a snowball.
(If your computer is as good as my new one, you might need to throw several snowballs to reproduce the problem.)
6. Observe the immediate freezing of the game.
Expected Outcome:
The `item_display` entities should seamlessly teleport without any disruption to the game's flow, ensuring a smooth playing experience.
Command blocks running commands for a lot of entities, or having a lot of command blocks producing some output will very quickly start lagging out the client or server. This seems to stem from the large amounts of log messages produced from the command blocks and does not happen with the commandBlockOutput gamerule disabled.
It seems that this issue is more likely to occur on computers with lower configurations. If your computer is as good as my new one, you might need to throw several snowballs to reproduce the problem.
Example steps to Reproduce:
1. Position a loop command block and configure it to be always active.
2. Input the first command: execute at @e[type=minecraft:snowball] run summon minecraft:item_display ~ ~ ~ {item:{id:'minecraft:diamond'},item_display:{gui:true}}
- This is used as a simple way to increase the load/log spam from the next command block in a controlled way
3. Place another loop command block and similarly configure it for perpetual activation.
4. Enter the second command: execute as @e[type=minecraft:item_display] at @s run tp @s ~ ~ ~ facing entity %YOUR_NAME%
- Remember to substitute `%YOUR_NAME%` with your actual Minecraft username.
5. Throw a snowball.
(If your computer is as good as my new one, you might need to throw several snowballs to reproduce the problem.)
6. Observe the immediate freezing of the game.
Fast/longcommand block outputcanresult in lagHaving a lot of command block output results in lag
Command blocks running commands for a lot of entities, or having a lot of command blocks producing some output will very quickly start lagging out the client or server. This seems to stem from the large amounts of log messages produced from the command blocks and does not happen with the commandBlockOutput gamerule disabled.
It seems that this issue is more likely to occur on computers with lower configurations. If your computer is as good as my new one, you might need to throw several snowballs to reproduce the problem.
Example steps to Reproduce:
1. Position a loop command block and configure it to be always active.
2. Input the first command: execute at @e[type=minecraft:snowball] run summon minecraft:item_display ~ ~ ~ {item:{id:'minecraft:diamond'},item_display:{gui:true}}
- This is used as a simple way to increase the load/log spam from the next command block in a controlled way
3. Place another loop command block and similarly configure it for perpetual activation.
4. Enter the second command: execute as @e[type=minecraft:item_display] at @s run tp @s ~ ~ ~ facing entity %YOUR_NAME%
- Remember to substitute `%YOUR_NAME%` with your actual Minecraft username.
5. Throw a snowball.
(If your computer is as good as my new one, you might need to throw several snowballs to reproduce the problem.)
6. Observe the immediate freezing of the game.
Command blocks running commands for a lot of entities, or having a lot of command blocks producing some output will very quickly start lagging out the client or server. This seems to stem from the large amounts of log messages produced from the command blocks and does not happen with the commandBlockOutput gamerule disabled.
It seems that this issue is more likely to occur on computers with lower configurations. If your computer is as good as my new one, you might need to throw several snowballs to reproduce the problem.
Example steps to Reproduce:
1. Position a loop command block and configure it to be always active.
2. Input the first command: execute at @e[type=minecraft:snowball] run summon minecraft:item_display ~ ~ ~ {item:{id:'minecraft:diamond'},item_display:{gui:true}}
- This is used as a simple way to increase the load/log spam from the next command block in a controlled way
3. Place another loop command block and similarly configure it for perpetual activation.
4. Enter the second command: execute as @e[type=minecraft:item_display] at @s run tp @s ~ ~ ~ facing entity %YOUR_NAME%
- Remember to substitute `%YOUR_NAME%` with your actual Minecraft username.
5. Throw a snowball.
(If your computer is as good as my new one, you might need to throw several snowballs to reproduce the problem.)
6. Observe the immediate freezing of the game.
is duplicated by
is duplicated by
duplicates
is duplicated by
relates to
is duplicated by
relates to
Thank you for your report!
We're tracking this issue in 276296, so this ticket is being resolved and linked as a duplicate.That ticket has already been resolved as Fixed. Please check the Fix Version/s field in that ticket to see in which version this behavior was or will be fixed.
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
duplicates
is duplicated by
duplicates
Importantis duplicated by
relates to
duplicates
relates to
duplicates
is duplicated by
BUG IN THE SPRUCE BOAT WITH CHESTSpruce boat translation key misspells "minecaft"
Spruce boat item translation key misspells "minecaft"
duplicates
Normalis duplicated by
is duplicated by
duplicates
Lowduplicates
relates to
duplicates
is duplicated by
relates to
is duplicated by
duplicates
is duplicated by
is duplicated by
duplicates
item_model component breakingitem_model item component breaks on trident
relates to
relates to
Thank you for your report!
However, this issue is Invalid.Entering and quitting a multiplayer server will also change the splash text. The text not updating when you simply go back without joining a server is consistent with the behavior from the singleplayer menu as well as world creation menu.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Splash text changes after going back fromSingleplayer (world creationscreen as I currently don't have any SP worlds), but not when going back from MultiplaserSplash text changes after going back from forced world creation menu of first world
When you go back from
SinglePlayer World Creation Screen (as I don't have any SP worlds yet), the splash text changes. When you go back fromServer list, it doesn't change.What I expected to happen was...:
The Splash text changed as if you would go back from SP
What actually happened was...:
The splash text remained the same.Steps to Reproduce:
1.Start Minecraft without any singleplayerworlds. Remember the splash text.
2. Go to Singleplayer World Creation screen
3. Go back with "cancel" and observe how the Splash text changed (try again if the splash text remained the same, there is a small chance to)
4. Go to Multiplayer
5. Go back with "cancel"
The splash text remained.When you go back from the very first singleplayer World Creation Screen (as I don't have any SP worlds yet), the splash text changes. When you go back from the world creation screen after you have already created a world, or the multiplayer server list, it doesn't change.
Steps to Reproduce:
1. Start Minecraft without any singleplayer worlds. Remember the splash text.
2. Go to Singleplayer World Creation screen
3. Go back with "cancel" and observe how the Splash text changed (try again if the splash text remained the same, there is a small chance to)
4. Actually create a world, exit it, and try step 2 and 3 again. Now the splash text will not change
relates to
relates to
duplicates
is duplicated by
duplicates
is duplicated by
relates to
relates to
duplicates
duplicates
is duplicated by
is duplicated by
is duplicated by
duplicates
is duplicated by
duplicates
is duplicated by
/tpruns twice if there's a block on the teleport point/tp teleports twice the relative distance if there's a block on the teleport point
The new lock field on container block entities stores an item predicate, but when placed as a block, the block entity decoding fails when the item predicate contains any registry/holder information.
How to reproduce:
- Give yourself a chest with the lock component
/give @s chest[lock={items:"minecraft:anvil"}]- Inspect the given item
/data get entity @s SelectedItemNotice that the command was valid and that the full lock component is present on the item
- Place the chest down
Notice that you can open the chest even when not holding an anvil
- Inspect the chest
/data get block <coords>- Repeat the same experiment with a lock predicate that isn't using registry access
/give @s chest[lock={count:4}]Code analysis:
The reason that decoding the lock field fails is that LockCode#fromTag uses CODEC.decode(NbtOps.INSTANCE, ..), specifically it uses the default NbtOpt instance. In contrast, the vault block entity for example constructs a DynamicOps using holderLookupProvider.createSerializationContext(NbtOps.INSTANCE).The new lock field on container block entities stores an item predicate, but when placed as a block, the block entity decoding fails when the item predicate contains any registry/holder information.
How to reproduce:
- Give yourself a chest with the lock component
/give @s chest[lock={items:"minecraft:anvil"}]- Inspect the given item
/data get entity @s SelectedItem- Place the chest down and re-enter singleplayer for the block entity to lose its lock data during deserialization
- Inspect the chest
/data get block <coords>- Repeat the same experiment with a lock predicate that isn't using registry access
/give @s chest[lock={count:4}]Code analysis:
The reason that decoding the lock field fails is that LockCode#fromTag uses CODEC.decode(NbtOps.INSTANCE, ..), specifically it uses the default NbtOpt instance. In contrast, the vault block entity for example constructs a DynamicOps using holderLookupProvider.createSerializationContext(NbtOps.INSTANCE).
duplicates
duplicates
is duplicated by
duplicates
duplicates
is duplicated by
duplicates
is duplicated by
is duplicated by
duplicates
is duplicated by
duplicates
is duplicated by
is duplicated by
MC-277272
duplicates
is duplicated by
duplicates
is duplicated by
duplicates
is duplicated by
is duplicated by
invisiblestuff and stuffdisappearingInvisible chests and items disappearing
Invisiblechests and items disappearingInvisible block entities and items disappearing
is duplicated by
duplicates
duplicates
Thank you for your report!
We're tracking this issue in MC-140857, 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
duplicates
duplicates
is duplicated by
is duplicated by
duplicates
is duplicated by
It only happens on multiplayer servers.
The command:
/particle dust 0 0 0 0 ~ ~ ~ 0 0 0 0 0
The kick message is:
Internal Exception: io.netty.handler.codec.DecoderException: java.io.IOException: Packet 0/35 (qk) was larger than I expected, found 12 bytes extra whilst reading packet 35
Code Analysis
Code analysis by [Mod] Nassim Jahnke can be found in this comment.
As well as pre4, hopefully this will get fixed OwO
The only SLIGHT difference can be found on the bottom, which is - still - quite useless and not noticeable
The delay is shorter, but still around 2, sometimes 3 ticks (and will be much worse on servers with just a little bit of lag), even in singleplayer on a flat world (= without much going on). Also, why check for people STARTING to sneak in the server? Wouldn't only checking the unsneak be sufficient to prevent any client abuse?
Yep, attached it (now it's also the correct one 👀)
Yet to be fixed in 1.14.1-pre1
The fov has nothing to do with the sprinting, it's just its symptom. The title is perfectly fine as "you sprint, you start sneaking, but don't actually stop sprinting"
Oh you're right, can't reproduce it anymore. Sorry then, just added the pre6 tag as the changelogs didn't make any mention of a change in this direction and it seemed too important to wait a day to test it.
So apparently this is fixed with pre6.
That's probably another cause, then. I cannot reproduce the cause/issue I'm referring to in pre3, so this in particular should be a new one.
Bugs should be tested on vanilla servers and clients, just to note.
(Though yes, it's been tested on both of those)
I rarely have any latency issues, but I can bet than anyone with them would prefer having ghost blocks than to just die when digging down a tower.
... though eitherway, discussing this won't really solve anything, Mojang will have to make a fix that covers both in the next update anyways. 👀
This has had a way more drastic impact for me: whereas I have around 150 fps in 1.14.4 in an unchanched vanilla world with a render distance of 20, it drops to 40 and sometimes visibly below 30 in that same area (both also after waiting for everything to load in).
Turning the distance down to 12 gives it a more stable 60-70, but still with quite a lot of occasional stutters
A comment by slicedlime was that the drop in FPS is a tradeoff for a lot of other fixes and rendering in general - which is understandable with a drop from 200->150 or even 100, since both are perfectly playable. But in my (and a few of my friends') case, visibily having it below 30 is definitely not worth the tradeoff.
Right, I can't reproduce the crash in 20w17a anymore either (tested same behavior and world between 1.15.2 and the snapshot) - so only the misplaced cursor remains
So I suppose a mod could close this issue and I will create a new one for the mismatched cursor specifically? (since the original crash issue seems to be resolved with one of the latest snapshots, at least since 17a)
Created a new issue for that now MC-181539
... or should misplaced clicking and the character removal be split into 2?
Created a separate issue for the character removal MC-181673
Fixed in 1.16 (converted into a warning for missing attributes).
Still with 1.16-pre8
@Galaxy_2Alex yes, I am (especially the end screenshot + having stars in the nether should eliminate all doubts about that)
Codewise, this is due to color vectors being written as doubles, but read as floats (see DustParticleOptions fromNetwork vs. DustParticleOptionsBase#writeToNetwork)
Still an issue in 1.17.1. As already stated, the issue stems from the following call in Boat#floatBoat
where you get the following values if placing a boat at feet height y=64 for example
This video shows where this can also be abused to clip through a bedrock layer, player bases and similar.
Is it possible that the update isn't fully live yet everywhere? The minecraft.net profile site still tells me the name with different case is already taken
Can confirm this still does not work for MSA (migrated) accounts.
I can confirm I had the same exact crash after just flying around a newly generated 21w37a world
Still an issue in 1.17.1 and 21w37a
Update suppression is a block physics bug, also used as an exploit to crash servers if you just follow a step by step tutorial, no need to be an expert or to use extra client mods (also, https://xkcd.com/1172/)
Actually nvm, you can kill this, apparently local hosts have special handling when it comes to verifying messages.
69387 doesn't apply to this, jukeboxes are actual item containers now and you can use the command to set records - you just can't remove them with the command
@Avoma The new title isn't fully correct; You can replace books, but you cannot remove them (or I suppose replace with air specifically). You also removed the jukebox part, which is part of the same issue
Can confirm, it looks weird with the bottom margin larger than the top
Affects 1.20.1
Can confirm, this will be very annoying for users on servers with network-wide resource packs
Affects 1.21 and is made worse with high client to server ping
Also affects soul speed, see uploaded video or https://streamable.com/ww0e4o
Due to the server first having to recalculate the enchantment attribute effect when ticking, there can be a considerable delay before/after effect start and end when going on and off soul sand while boots are equipped
Added an updated command, valid in 1.21.1
Added an updated command, valid in 1.21.1
Thank you for your report!
We're tracking this issue in
MC-42868, so this ticket is being resolved and linked as a duplicate. You need to instead break one of the supporting obsidian blocks.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
Added a specific example command to the second step, can still reproduce
The teleporting itself doesn't seem to cause issues on my end, but the logging alone might play an important factor here, though this can depend a lot on the OS/system.
Do you have the commandBlockOutput gamerule enabled or disabled? Please make sure to test with the output disabled.
Thank you for your report!
However, this issue is Invalid.
You have posted a feature request or a suggestion. This site is for bug reports only.
For suggestions, please visit The Minecraft Feedback Site or visit the Minecraft Feedback Discord server.
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!
However, this issue is Invalid.
You have posted a feature request or a suggestion. This site is for bug reports only.
For suggestions, please visit The Minecraft Feedback Site or visit the Minecraft Feedback Discord server.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
The command is indeed no longer valid in 24w36a due to item food component changes, could you update it?
Thank you for your report!
We're tracking this issue in
MC-276322, so this ticket is being resolved and linked as a duplicate.That ticket has already been resolved as Fixed. Please check the Fix Version/s field in that ticket to see in which version this behavior was or will be fixed.
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-276322, so this ticket is being resolved and linked as a duplicate.That ticket has already been resolved as Fixed. Please check the Fix Version/s field in that ticket to see in which version this behavior was or will be fixed.
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-17184, 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
Looks valid to me, reproducible in singleplayer. Only applies to spruce boats. The translation key is misspelled as "minecaft"
Please open a separate ticket for the use_remainder issue on arrows etc. and include reproduction steps for that specifically
Thank you for your report!
However, this issue is Invalid.
The generic prefix and co. were removed in 24w33a, removing them in your command should make it work again.
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-72774, 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
Thank you for your report!
We're tracking this issue in
MC-95555, 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
Thanks for confirming, I updated the report to focus more in the logging part than the teleportation
Thank you for your report!
We're tracking this issue in
MC-87184, 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
I cannot reproduce this in 24w37a in singleplayer. Can you please elaborate on specific reproduction steps?
We do not have enough information to reproduce this issue.
Please include the following information to help us understand your problem:
Please also attach any needed commands, add-ons/behavior packs, data packs, resource packs, screenshots, videos, or worlds needed to help reproduce this issue.
Refer to the Bug Tracker Guidelines for more information about how to write helpful bug reports. Bug reports with insufficient information may be closed as Incomplete.
This issue is being temporarily resolved as Awaiting Response. Once the requested information has been delivered, the report will be reopened automatically.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
As per
MC-268931, the splash text not changing from the multiplayer menu is working as intended. However, I reopened the report and swapped around your expected and actual observations to highlight the inconsistency within the singleplayer world creation menu, which seems valid.Thank you for your report!
We're tracking this issue in MC-276826, 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
Thank you for your report!
We're tracking this issue in
MC-186105, 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
We do not have enough information to find the cause of this issue.
Please attach the crash report found in minecraft/crash-reports/crash-<DATE>-client.txt here.
If you cannot find a crash report, please attach the full launcher log found in minecraft/launcher_log.txt.
This issue is being temporarily resolved as Awaiting Response. Once the requested information has been delivered, the report will be reopened automatically.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Added half a step for re-entering singleplayer to actually go through the broken deserialization. An alternative that'll already go through serialization before a world save is
/data merge block ~ ~ ~1 {lock:{items:"minecraft:anvil"}}Thank you for your report!
We're tracking this issue in
MC-95555, 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-272517, 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
This might be the same as
MC-277001, could you try the soul sand setup explained there?Thank you for your report!
We're tracking this issue in
MC-273378, 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!
However, this issue is Working as Intended.
The report you have submitted is working as intended.
Please note, that mechanics of the game may change between updates.
Things such as graphics, sounds, world creation, biomes, redstone, villagers, and animals may not work the same in current versions.
Full Version History – Snapshot Version History – Feature Requests and Suggestions
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-277195, 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
Thank you for your report!
We're tracking this issue in
MC-277144, so this ticket is being resolved and linked as a duplicate.That ticket has already been resolved as Fixed. Please check the Fix Version/s field in that ticket to see in which version this behavior was or will be fixed.
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-277144, so this ticket is being resolved and linked as a duplicate.That ticket has already been resolved as Fixed. Please check the Fix Version/s field in that ticket to see in which version this behavior was or will be fixed.
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-277129, 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
The different cases you described here might get different resolutions (e.g.
MC-276619), splitting them up means it's more likely that the individual ones will be triaged and fixed. A lot of those come down to behavior of specific items, so a general "it's inconsistent" isn't enough to have them known and addressedThank you for your report!
However, this issue is Invalid.
You have posted a feature request or a suggestion. This site is for bug reports only.
For suggestions, please visit The Minecraft Feedback Site or visit the Minecraft Feedback Discord server.
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-220842, 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
Which version transitions caused which issues? In order to use the latest world upgrading features, you would have had to jump from 1.8 to 1.21.1, or at least a version past the Caves and Cliffs update. Issues from upgrading to previous versions can't be fixed retroactively
Thank you for your report!
However, this issue is Invalid.
Your game, launcher or server is modified.
If you can reproduce the issue in a vanilla environment, please recreate the issue.
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-277502, 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
Thank you for your report!
However, this issue is Invalid.
Your game, launcher or server is modified.
If you can reproduce the issue in a vanilla environment, please recreate the issue.
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-277548, so this ticket is being resolved and linked as a duplicate.If you would like to add a vote and any extra information, like errors from world upgrading 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
Thank you for your report!
We're tracking this issue in
MC-277548, 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
Can you provide a world download, possibly also from before upgrading to pre2 or 3?
Thank you for your report!
However, this issue is Invalid.
Your game, launcher or server is modified and also outdated.
If you can reproduce the issue in a vanilla environment, please recreate the issue.
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-277548, so this ticket is being resolved and linked as a duplicate.That ticket has already been resolved as Fixed. Please check the Fix Version/s field in that ticket to see in which version this behavior was or will be fixed.
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!
However, this issue is Invalid.
You have posted a feature request or a suggestion. This site is for bug reports only.
For suggestions, please visit The Minecraft Feedback Site or visit the Minecraft Feedback Discord server.
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-266088, 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-277400, so this ticket is being resolved and linked as a duplicate.That ticket has already been resolved as invalid. Please take a look at the parent ticket (
MC-277400) and see if an explanation is provided there in the description of the ticket or in the comments for why this issue is invalid.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 was able to reproduce this given the world download after using the command block and teleporting back after a bit, though it seems like it is "just" the client not getting or processing the block breaks properly. They appear to be correctly destroyed on the integrated server, no duping
Additional context I could observe is that it applies to more than just xp orbs, e.g. applying negative y delta movement to an item that is sitting on the ground will also make it bounce upwards visually. This also does not seem to stem from server-side movement and the resulting entity motion packets, but from how the client then processes/applies those packets
Thank you for your report!
We're tracking this issue in
MC-275510, 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.
You can request a re-review of the other report by joining the Mojira Discord, but as is this is a duplicate.
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!
However, this issue is Invalid.
The client jar as it is found in your versions folder does not include the bundler, so the bundler main class argument doesn't do anything.
This is a technical support issue; this site is for bug reports only. We do not have the resources to provide you with technical support.
Please contact Community Support for assistance and refer to this ticket by providing a link.
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!
However, this issue is Invalid.
Your Minecraft version is outdated or modified. We only take issues for the latest release and the latest snapshot.
Please update to the latest version as it includes the newest fixes. If you still have this problem after updating, then please create a new issue.
In case of a game crash, please also attach the crash report found in minecraft/crash-reports/crash-<DATE>-client.txt.
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!
However, this issue is Invalid.
You have posted a feature request or a suggestion. This site is for bug reports only.
For suggestions, please visit The Minecraft Feedback Site or visit the Minecraft Feedback Discord server.
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!
However, this issue is Invalid.
You have posted a feature request or a suggestion. This site is for bug reports only.
For suggestions, please visit The Minecraft Feedback Site or visit the Minecraft Feedback Discord server.
As per the changelogs, has_component checks whether a component type is present, what you're trying to do is something different.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Please attach a screenshot or video of the issue and elaborate on what "unspecified" means in the context of the debug menu.
This issue is being temporarily resolved as Awaiting Response. Once the requested information has been delivered, the report will be reopened automatically.
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-278518, 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
You jump higher than one block, so the fall distance is greater than 4 blocks compared to simply walking off a block.
Thank you for your report!
However, this issue is Invalid.
Your game, launcher or server is modified.
If you can reproduce the issue in a vanilla environment, please recreate the issue.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
You didn't provide enough emeralds for the mending enchantment trade.
Thank you for your report!
However, this issue is Invalid.
Your game, launcher or server is modified.
If you can reproduce the issue in a vanilla environment, please recreate the issue.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
You have to use append to expand an array, you can't set a value that doesn't exist. The error message being misleading would be a different issue, see MC-255915 and MC-176679 for example
Thank you for your report!
However, this issue is Invalid.
Your game, launcher or server is modified.
If you can reproduce the issue in a vanilla environment, please recreate the issue.
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-118001, 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
Thank you for your report!
However, this issue is Invalid.
Formatting codes are considered deprecated, see the comment below, as well as https://bugs.mojang.com/browse/MC-190605?focusedCommentId=993040&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-993040
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Have you tried disabling sync-chunk-writes in the server.properties file? The option was introduced a few versions ago and I believe this defaults to true on Windows to fix some other issues
None of these were present in the version before the fix (being 1.21.3), so your observed behavior is not a regression or a bug - your expected behavior however would be. As far as I can see, it was reverted to how it was before. Can you elaborate on what you mean by "this did not happen"?
If there was a regression around elytras, please make a separate report and explain that example in more detail
Thank you for your report!
However, this issue is Invalid.
When considering bugs, you need to show their in-game impact and compare it with previous behavior. In this case, the code might look slightly different, but as far as we can see, the behavior is the same and is more of a feature suggestion.
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!
However, this issue is Invalid.
Simply stating that "My game is laggy" is not helpful for Mojang to diagnose your issue. If you can pinpoint a specific cause when lag happens for you, please open a new report for that specific issue. If you think this might be a hardware issue please contact Community Support as they might be able to help with your issue.
Keep in mind that Mojang is constantly optimizing the game and simply playing the game provides feedback to Mojang on which parts cause performance issues. To learn more about this, head here (section "Telemetry") for more information.
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!
However, this issue is Invalid.
Your Minecraft version is outdated. We only take issues for the latest release and the latest snapshot.
Please update to the latest version as it includes the newest fixes. If you still have this problem after updating, then please create a new issue.
In case of a game crash, please also attach the crash report found in minecraft/crash-reports/crash-<DATE>-client.txt.
Modified versions are not accepted for bug reports either.
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!
However, this issue is Invalid.
Your Minecraft version is outdated. We only take issues for the latest release and the latest snapshot.
Please update to the latest version as it includes the newest fixes. If you still have this problem after updating, then please create a new issue.
In case of a game crash, please also attach the crash report found in minecraft/crash-reports/crash-<DATE>-client.txt.
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!
However, this issue is Invalid.
Your game, launcher or server is modified.
If you can reproduce the issue in a vanilla environment, please recreate the issue.
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-270919, 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
Thank you for your report!
However, this issue is Invalid.
Your game, launcher or server is modified.
If you can reproduce the issue in a vanilla environment using the latest release or snapshot version, please recreate the issue.
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!
However, this issue is Invalid.
Simply stating that "My game is laggy" is not helpful for Mojang to diagnose your issue. If you can pinpoint a specific cause when lag happens for you, please open a new report for that specific issue. If you think this might be a hardware issue please contact Community Support as they might be able to help with your issue.
Keep in mind that Mojang is constantly optimizing the game and simply playing the game provides feedback to Mojang on which parts cause performance issues. To learn more about this, head here (section "Telemetry") for more information.
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!
However, this issue is Invalid.
Your game, launcher or server is modified.
If you can reproduce the issue in a vanilla environment, please recreate the issue.
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!
However, this issue is Invalid.
You have posted a feature request or a suggestion. This site is for bug reports only.
For suggestions, please visit The Minecraft Feedback Site or visit the Minecraft Feedback Discord server.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Please make sure you are using an unmodded version of Minecraft through the default launcher, using the latest version of Minecraft. The same applies to the server you are connecting to, as these servers are not running latest or vanilla. 1.21.4 does not run on Java 17 but should come with its own bundled version of Java 21. Otherwise this is likely to stem from something outside of the game