luan_wo_xin_zhe

This could be an issue with the third-party launcher.

这有可能是第三方启动器（例如PCL）的问题。

In the latest snapshot(26.4 Snapshot 7): Shooting a projectile into the water of a geyser causes it to repeatedly teleport/rubberbanding up and down.

@mightytuniek

Since the information you provided is highly technical and very lengthy, I am unable to understand and verify it, and I am not sure whether it is appropriate to include it within the scope of this ticket. Therefore, I will not modify the ticket description for now.

In the latest snapshot(26.4 Snapshot 7):

/summon minecraft:polar_bear ~ ~ ~ {Age:-25000}
/execute as @e[type=minecraft:polar_bear,limit=1,sort=nearest] run data merge entity @s {anger_end_time: 20000L}
/execute as @e[type=minecraft:polar_bear,limit=1,sort=nearest] run data modify entity @s angry_at set from entity @p UUID

In the latest snapshot(26.4 Snapshot 6), I can see the bottom of frozen water through lightning.

from wiki

@[Team Allay] EmA

You said it was Duplicate, but why is it actually Fixed?

After consulting a mod developer, the following investigation results were obtained:

Background ①: When creating an OpenGL context, a window must be provided to bind to it.

Background ②: SDL internally and permanently caches the HWND of the first window created, for use by input method operations.

Background ③: In Snapshot 9, the timing of window creation changed from the original “create hidden window → create OGL context → show window” to “create OGL context → directly create visible window.”

In terms of implementation details, Snapshot 8’s OGL context binds directly to the real game window, whereas Snapshot 9 binds to a temporary window upon creation. This causes SDL’s cached HWND to become that temporary window, making it impossible to perform input method operations on the real game window created later.

In other words, under SDL, the first window created must be the real game window. The Vulkan backend, because it has no mandatory initialization requirement to bind to a window, does not have any temporary window.

After consulting a mod developer, the following investigation results were obtained:

Background ①: When creating an OpenGL context, a window must be provided to bind to it.

Background ②: SDL internally and permanently caches the HWND of the first window created, for use by input method operations.

Background ③: In Snapshot 9, the timing of window creation changed from the original “create hidden window → create OGL context → show window” to “create OGL context → directly create visible window.”

In terms of implementation details, Snapshot 8’s OGL context binds directly to the real game window, whereas Snapshot 9 binds to a temporary window upon creation. This causes SDL’s cached HWND to become that temporary window, making it impossible to perform input method operations on the real game window created later.

In other words, under SDL, the first window created must be the real game window. The Vulkan backend, because it has no mandatory initialization requirement to bind to a window, does not have any temporary window.

This might be the cause of the issue: "The third-person view camera has a collision that collides with block visual box. This can obstruct the player's vision with a close-up view in some situation where solid blocks are placed behind or in front of the player."

https://minecraft.wiki/w/Third-person_view

The third-person camera is by default located 4 blocks in front of or behind the player, but if the player suffocates in this mode, the distance seems to become 0 blocks. This can be confirmed by entering the following command:

/attribute @s minecraft:camera_distance base set 0

The software I use does not affect game performance.

My "Controls" settings remain at the game's default values and have not been changed.

@clamlol

This is the same issue as MC-91132, isn't it?

@clamlol

This is the same issue as MC-308804, isn't it?

During the period from 26.3 Snapshot 4 to 26.3 Snapshot 8, the issue was fixed. Starting from 26.3 Snapshot 9, the issue reappeared (the Microsoft IME has no problem, but the third-party input methods have problems).

Request to reopen this issue. In 26.3 Pre-Release 1, among the input methods I have installed, only the Microsoft IME has been fixed; the other two third-party input methods still have issues.

MC—311034：Regardless of whether Exclusive Fullscreen is enabled or disabled, Minecraft always enters Exclusive Fullscreen mode when fullscreen is enabled.

MC-311034 may cause this.

MC—311034：Regardless of whether Exclusive Fullscreen is enabled or disabled, Minecraft always enters Exclusive Fullscreen mode when fullscreen is enabled.

MC-311034

Why are the Mojang Priority different?

Issue update: In 26.2, the system input method is always used, and the emoji panel displays normally; after using the game's built-in IME in the 26.3 snapshots, the emoji panel completely fails to display, and other keys do not respond unless the Esc key is pressed.