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"?
Please reconsider resolving this issue. I know it's impossible to add commands to control player orientation and movement, so I hope this at least solves the problem.
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.
With that workaround, if a mob receives damage that exceeds the sum of its health and absorption (4056) at once, isn't there a problem that the calculation cannot be performed and the mob dies?
I'm not sure if this applies to your use case, but in the custom map we're creating, there are mobs with over 10,000 HP. Since the health limit is 2048, the map was using AbsorptionAmount instead.
I am in trouble because from now on it will be impossible to create mobs with very high health.
This bug seems to occur even if item_display, block_display, or text_display is not mounted by any entity
I made items that need to "charge" like tridents...
I think reduce the way you make something is not cool.
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.