Chuzume

I'm leaving this solution here for anyone who is still suffering from the same problem as me.

Solution:
Download the latest version from the OpenAL-Soft repository.(https://github.com/kcat/openal-soft/releases )
Unzip the downloaded file and run alsoft-config.exe located in the openal-soft folder.
Change "Channels" in the “Playback” tab from "Autodetect" to “Stereo”, then click Apply to close.
Start the game and check if HRTF works.

I'm leaving this solution here for anyone who is still suffering from the same problem as me.

Solution:
Download the latest version from the OpenAL-Soft repository.(https://github.com/kcat/openal-soft/releases )
Unzip the downloaded file and run alsoft-config.exe located in the openal-soft folder.
Change "Channels" in the “Playback” tab from "Autodetect" to “Stereo”, then click Apply to close.
Start the game and check if HRTF works.

This issue occurred in my environment as well, and since it became a significant problem after the 26.1 update, I investigated it further.

At least in my environment, switching to an analog headphone connection enabled the ability to switch Directional Audio in-game (of course, the sound quality was considerably lower compared to the USB connection).

Previously, this problem did not occur by explicitly specifying the OpenAL.dll used in 1.20.2 as a JVM argument and using it with other versions.

Incidentally, this method should not be used in 26.1, as older versions of OpenAL.dll cause crashes.

From these points, it seems the problem lies with OpenAL, not Minecraft. Perhaps it stopped supporting USB headphones at some point in the update?

the above option in version 26.1 will prevent the system from starting.

This is due to an outdated version of OpenAL; updating OpenAL will render HRTF unusable. Unfortunately, we have no further options.

If Mojang isn't going to fix this, they should go with WAI.

This restriction can be circumvented by setting the function permission level to 3 or higher in the server settings, which allows the op command, and granting op permission only while the player has the menu open. However, this is not possible on Realms or LAN servers, where the function permission level cannot be changed. Also, granting op permission to any player, even if only temporarily, can be a vulnerability for the server...

It seems Mojang has decided not to fix this, so this is probably the intended behavior. It's a bug that only affects certain people, so it will never be fixed.

The Ender Dragon's DragonPhaseNBT of 8 means that it will charge the player, but even if you force it to 8 with a command, it will immediately revert to 0. It is possible to change it to Every Tick8, but it will not charge the player and will behave the same as when DragonPhase is 0.

@ToFall 24w33a is a snapshot of 1.21.2, so I think it should be fixed in 1.21.4 as well.
Or is it invalid if it's fixed in 1.21.2 but reoccurs in 1.21.4?

For example, if you are looking straight down and execute

/tp @s ~ ~ ~ ~ ~-180

you would expect the user to look straight up, but in reality they will stop in front of you.

The Rotate command seems to make them look straight up without any problems

/rotate @s ~ ~-180

It used to be possible to specify a different version of the OpenAL library in a Java argument, but it doesn't seem to work anymore. It just crashes the game.

In the example below, the OpenAL dll version 3.3.1 placed directly under .minecraft is specified, but the game crashes just as if nothing was specified. It seems to have been fixed.

It was my mistake. The crash was caused by a space before the path specification. I've written it below so that no one else makes the same mistake.

People who are experiencing this bug probably had it working fine in 1.20.1 or earlier, so specifying the OpenAL library used in 1.20.1 may solve the problem.

I had the opposite problem of not being able to turn on Directional Audio, but this solved it.

Once you start up with 1.20.1, a folder named "3.3.1" should be created in ".minecraft\libraries\org\lwjgl\lwjgl-openal". Open or unzip "lwjgl-openal-3.3.1-natives-windows.jar" in that folder using the appropriate method (such as using 7zip), and copy "OpenAL.dll" from "lwjgl-openal-3.3.1-natives-windows.jar\windows\x64\org\lwjgl\openal" and place it wherever you like, such as in ".minecraft".

After that, please specify the following in the JVM arguments section of the launcher startup settings. Change the username etc. to suit your environment.

// Not work
-Dorg.lwjgl.openal.libname= "C:\Users\yourname\AppData\Roaming\.minecraft\OpenAL.dll" 


// Work
-Dorg.lwjgl.openal.libname="C:\Users\yourname\AppData\Roaming\.minecraft\OpenAL.dll"

I looked into it, and it turns out that 1.20.1 uses openal version 3.3.1, 1.20.2 uses 3.3.2, and 1.21 uses 3.3.3. For some reason, 3.3.2 or later doesn't work on my computer, so I can't enable directional audio. This may be an environment-dependent issue.

If I could continue using the 3.3.1 version, this bug would be solved, but even if I renamed the 3.3.1 file and put it in the 3.3.3 folder, it would be downloaded every time Minecraft starts, so this is not possible.

The problem I'm experiencing is the complete opposite, but yes, I couldn't solve it using the methods written there.

Please reconsider this specification. This method is required to create a custom weapon on command that can be held like a gun. Detection of right-clicks using things like Food is incomplete due to unavoidable slowdown.

Please reconsider this

It is true that this change greatly limits creative freedom. There may be reasons such as wanting to make the custom GUI only for the Bedrock edition, but shouldn't it be possible to return to the previous specifications or control it with CustomNameVisible?

This bug has not been fixed for years and is still unassigned. This suggests that Mojang is either unwilling to fix this bug or is unable to fix it for technical reasons. Shouldn't the resolution for this bug be "work as intended" or "will not fix"?

All attackable entities, not just Interaction, may not take damage when clicked immediately after being summoned. At this time, the block behind the mob cannot be destroyed, so it seems that it is attacking something that is neither a mob nor a block.

Isn't this bug "work as intended"?

At least in our map, we need to deal a lot of damage from a user experience perspective, and lowering weapon damage is probably not a direct solution.