Amura Yuka
- Chuzume
- chuzume
- Europe/Stockholm
- Yes
- No
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
MC-260848
NormalMC-266279MC-277406
Put the summary of the bug you're having here
What I expected to happen was...:
Cannot drop items from the inventory when I changed drop key
"Q" to "\"What actually happened was...:
↑Same onSteps to Reproduce:
1. Go to "Control
2. Change "Drop Selected Item" key "Q" to others. Select "Done"
3. Cannot drop items from the inventory.Put the summary of the bug you're having here
What I expected to happen was...:
Cannot drop items from the survival inventory when I changed drop key
"Q" to "\"
I mean this inventory(http://i.imgur.com/KmDX0pH.png)
Not this(http://i.imgur.com/dV2H890.png)What actually happened was...:
↑Same onSteps to Reproduce:
1. Go to "Control
2. Change "Drop Selected Item" key "Q" to others. Select "Done"
3. Cannot drop items from the inventory(http://i.imgur.com/KmDX0pH.png)
OK you don't know quick drop. right?
I can not explain what the quick drop.
I give up
I added screen shots
Yes. But I think this bug is It occurs only in my minecraft.
What I expected to happen was...:
Specify the "air" in the Vex's right hand.
He has a Iron Sword in right hand.What actually happened was...:
...same on?Steps to Reproduce:
1.Do this./summon Vex ~ ~ ~ {HandItems:[{id:air,Count:1},{}]}(If you say it's specification. I want
tochange this specification.)
I cannot empty his hand when use that command.
And, when act summon command. This make same result.
Game crashed when try check"Charged:1b"crossbow in inventoryGame crashed when try check null loaded crossbow in inventory
To reproduce
1:Get item with this command.
/give @s crossbow{charged:1b}2:Open inventory, and place the cursor over that crossbow.
3:Crash.
---- Minecraft Crash Report ---- // Why is it breaking :( Time: 19/03/17 17:55 Description: Rendering screen java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(ArrayList.java:653) at java.util.ArrayList.get(ArrayList.java:429) at azj.a(SourceFile:383) at bar.a(SourceFile:589) at cyg.a(SourceFile:108) at cyg.a(SourceFile:104) at czn.a(SourceFile:735) at cza.b(SourceFile:182) at czn.a(SourceFile:685) at djc.a(SourceFile:688) at ctp.d(SourceFile:970) at ctp.b(SourceFile:413) 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 thread Stacktrace: at java.util.ArrayList.rangeCheck(ArrayList.java:653) at java.util.ArrayList.get(ArrayList.java:429) at azj.a(SourceFile:383) at bar.a(SourceFile:589) at cyg.a(SourceFile:108) at cyg.a(SourceFile:104) at czn.a(SourceFile:735) at cza.b(SourceFile:182) at czn.a(SourceFile:685) -- Screen render details -- Details: Screen name: czn Mouse location: Scaled: (458, 305). Absolute: (916.000000, 611.000000) Screen size: Scaled: (960, 509). Absolute: (1920, 1017). Scale factor of 2.000000 -- Affected level -- Details: Level name: MpServer All players: 1 total; [dip['Chuzume'/108, l='MpServer', x=39.52, y=65.00, z=-136.45]] Chunk stats: MultiplayerChunkCache: 441, 337 Level seed: 0 Level generator: ID 01 - flat, ver 0. Features enabled: false Level generator options: {} Level spawn location: World: (48,64,-256), Chunk: (at 0,4,0 in 3,-16; contains blocks 48,0,-256 to 63,255,-241), Region: (0,-1; contains chunks 0,-32 to 31,-1, blocks 0,0,-512 to 511,255,-1) Level time: 1907000 game time, 1000 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: creative (ID 1). Hardcore: false. Cheats: false Server brand: vanilla Server type: Integrated singleplayer server Stacktrace: at dgf.a(SourceFile:447) at ctp.b(SourceFile:1936) at ctp.b(SourceFile:421) at net.minecraft.client.main.Main.main(SourceFile:154) -- System Details -- Details: Minecraft Version: 19w11b 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: 711106168 bytes (678 MB) / 1979711488 bytes (1888 MB) up to 2147483648 bytes (2048 MB) JVM Flags: 9 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xss1M -Xmx2G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M Launched Version: 19w11b LWJGL: 3.2.1 build 12 OpenGL: GeForce GTX 1060 3GB/PCIe/SSE2 GL version 4.6.0 NVIDIA 419.35, 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/Randomobs.zip (incompatible), file/Vertical Slab, file/addtion_default, file/Test Current Language: 日本語 (日本) CPU: 8x Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz
What I expected to happen was...
Trident model will change same as before 1.15
What actually happened was...
It ignores "layer0" and "elements" section. It only use "display" section.
Step to reproduce
1.Apply "Trident_Report" Resourcepack.
2.Do/give @s minecraft:trident{CustomModelData:1}3.You'll get weird trident instead of a iron sword model Trident.
[Mod] NeunEinser I made items that need to "charge" like tridents...
I think reduce the way you make something is not cool.
I always wonder, Mojang should mark bugs like this as "Work as intended " or "Won't fix" if it doesn't intend to fix it.
They cannot add even marker armor stand that have gravity.
Like Marker:2b
Isn't this an intended behavior rather than a bug? I think the dev team's answer is that if you need interpolation, you should use an armor stand.
What I expected to happen was...
Attacking mobs with AbsorptionAmount set to 2049 or higher will still be calculated correctly as in previous versions
What actually happened was...
Even if AbsorptionAmount is set to 2049 or higher, it will be treated as if it were 2048.Step to reproduce
Run the following commands in order.
/summon creeper
/attribute @e[type=creeper,limit=1] minecraft:generic.max_absorption base set 20000
/data modify entity @e[type=minecraft:creeper,limit=1] AbsorptionAmount set value 20000f
Then attack the mob and get the data using the command below.
/data get entity @e[distance=0.5..,sort=nearest,limit=1] AbsorptionAmountData is displayed as damage based on 2048, not 20000.
In previous versions, it was possible to set a value much larger than 2048 because the maximum value was not tied to an Attribute, but this is no longer possible in the current version.
Description of bug:
In versions 1.20.2 and later, turning HRTF on from the options is meaningless.
Steps to Reproduce:
Just toggle HRTF in the sound options and hear the difference - there is a difference in the sound when you click on the UI in 1.20.1, but no difference in 1.20.2.Workaround:
Description of bug:
In versions 1.20.2 and later, turning HRTF on from the options is meaningless.
Steps to Reproduce:
Just toggle HRTF in the sound options and hear the difference - there is a difference in the sound when you click on the UI in 1.20.1, but no difference in 1.20.2.{}
I would like to know how to trigger this bug. I am experiencing the opposite bug where directional audio is disabled even when turned on.
In 1.20.1, Openal version 3.3.1 is used, in 1.20.2 it is 3.3.2, and in 1.21 it is 3.3.1. For some reason, 3.3.2 and later don't work on my computer and remain off, but it may remain on due to differences in the Openal version, and this may be environment-dependent.
This bug would be solved if I could continue using version 3.3.1, but this is not possible as it is downloaded every time I start the computer.
Currently the fix using JVM arguments may not work, it will just crash.
Previously, values above 1 would still affect the colors of
things like dust. For example, very large values could be used to create colors that were not possible with the normal color settings.
The screenshot showing the yellow particleswas taken in 1.21.1.Here is an example command:
/particle minecraft:dust{color:[100000000.0,100000000.0,1.0],scale:1} ~ ~ ~ 1 1 1 0 1000However, in 1.21.2-PreRelease 1, any value above 1 seems to be treated as 1.
The screenshot showing the white particles was taken using the same command in the pre-release.Previously, values above 1 would still affect the colors of particles like "dust".
For example, very large values could be used to create colors that were not possible with the normal color settings.
The screenshot showing the yellow particles was taken in 1.21.1.Here is an example command:
/particle minecraft:dust{color:[100000000.0,100000000.0,1.0],scale:1} ~ ~ ~ 1 1 1 0 1000However, in 1.21.2-PreRelease 1, any value above 1 seems to be treated as 1.
The screenshot showing the white particles was taken using the same command in the pre-release.
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
Amura Yuka I agree. And it is most certainly a bug. I am sure there are other rps that would like to change the trident as well, without wanting it to use as simple right click detection 
. I was mostly suggesting an alternative for the right click detection in case that it doesn't get fixed in 1.15.
Infinite Corners I already marked it as "Confirmed".
In 16w40a.
I successfulempty its hand with /summon
/summon Vex ~ ~1 ~ {ArmorItems:[{},{},{},{id:air,Count:1}]}When specified air to the head, its hand is empty.
But Specified air to the mainhand. its has iron sword.
Why this is "Works As Intended"? it should be changed.
Attached the crash report.
Sadly, unlike before 1.15,Trident will thrown even it have negative "Riptide" enchant.
So, we cannot make trident like right-click active item with command even if this problem fixed.
I made items that need to "charge" like tridents...
I think reduce the way you make something is not cool.
This bug seems to occur even if item_display, block_display, or text_display is not mounted by any entity
I am in trouble because from now on it will be impossible to create mobs with very high health.
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.
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?
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.
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.
Isn't this bug "work as intended"?
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.
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"?
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?
Please reconsider this
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.
The problem I'm experiencing is the complete opposite, but yes, I couldn't solve it using the methods written there.
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.
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.
For example, if you are looking straight down and execute
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
@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?
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.