mojira.dev

Chuzume

Assigned

No issues.

Reported

MC-279848 follow_range attribute not working for piglins Awaiting Response MC-277406 Particles that can change color, such as dust, no longer accept values ​​above 1 Works As Intended MC-274749 HRTF is disabled even when turned on Duplicate MC-270289 Can't charge crossbow with air Works As Intended MC-267897 When a named Minecart is placed, the name is displayed when the cursor is placed on it, and it cannot be hidden even if CustomNameVisible is set to False. Duplicate MC-266279 Interactions immediately after summoning will not trigger Advancement or your own NBT, even if clicked occasionally. Awaiting Response MC-265785 In multiplayer, teleport command behavior is inconsistent between host and participant. Duplicate MC-265321 Absorption Amount cannot be set to 2049 or higher Confirmed MC-263034 Left side bearing/kerning is treated as double when using TrueType fonts Won't Fix MC-260848 Mounting other entities on item_display, block_display, or text_display entity causes inconsistent behavior Awaiting Response MC-166072 Custom Trident model ignores "layer0" and "elements" section Fixed MC-146008 Game crashed when try check null loaded crossbow in inventory Duplicate MC-123124 /execute doesn't work well Duplicate MC-119317 Can't detect torch and more Invalid MC-107494 Cannot summon Vex with empty right hand Fixed MC-107069 (Added more info) Cannot drop items from the survival inventory when I changed drop key Duplicate MC-107047 Cannot drop items from the inventory when changed drop key. Duplicate

Comments

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"?

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.