Roark
- RoarkCats
- JIRAUSER504932
- America/Los_Angeles
- Yes
- No
MC-195214
Low![[Mojang] eowyn36](../../../data/avatars/users/18935.svg){kind=small}
Normal
The end credits conversation/text uses "realised" with the English US language setting, in US English "realized" is the proper spelling.
This occurs only once about two-thirds down in the line "Shush... Sometimes the player read lines of code on a screen. Decoded them into words; decoded words into meaning; decoded meaning into feelings, emotions, theories, ideas, and the player started to breathe faster and deeper and realised it was alive, it was alive, those thousand deaths had not been real, the player was alive"
The end credits conversation/text uses "realised" with the English US language setting, in US English "realized" is the proper spelling.
This occurs only once about two-thirds down in the line "Shush... Sometimes the player read lines of code on a screen. Decoded them into words; decoded words into meaning; decoded meaning into feelings, emotions, theories, ideas, and the player started to breathe faster and deeper and realised it was alive, it was alive, those thousand deaths had not been real, the player was alive"
/give @s chest[minecraft:container=[{slot:-1,item:{id:'stone'}}]]This
returnedanerror when I ran it, then crashed a moment later and continues to crash when I open the chat after loading in. Removingthe command from my command history filefixes this.The game crashed whilst keypressed event handler
Error: java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 0/give @s chest[minecraft:container=[{slot:-1,item:{id:'stone'}}]]This command when pasted in crashes the game. (crash report .10.29) When I change the slot value to 1, run it, then edit it in the chat to -1, and run it, it errors and when I try to go back to the command via my history it crashes. It continues to do this when trying to access it from history until I manually edit and remove the command from my command history file.
Launcher crash notes:
The game crashed whilst keypressed event handler
Error: java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 0
/give @s chest[minecraft:container=[{slot:-1,item:{id:'stone'}}]]This command when pasted in crashes the game. (crash report .10.29) When I change the slot value to 1, run it, then edit it in the chat to -1, and run it, it errors and when I try to go back to the command via my history it crashes. (crash report .11.57) It continues to do this when trying to access it from history (crash report .12.42) until I manually edit and remove the command from my command history file.
Launcher crash notes:
The game crashed whilst keypressed event handler
Error: java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 0
Ominous Item Spawners store their item nbt under "item" likely causing /item and /loot replace to be unable to affect them in any slot, the "contents" slot included, as other entities store their item nbt under "Item" capitalized (item, item_frame, etc)
Steps to Reproduce:
1. /summon ominous_item_spawner ~ ~ ~ {spawn_item_after_ticks:50,item:{id:"stone",count:1}}
2a. /item replace entity @n[type=ominous_item_spawner] contents with dirt
2b. /loot replace entity @n[type=ominous_item_spawner] contents loot blocks/dirtObserved Results:
The ominous_item_spawner and the item it drops remain stone; the commands in step 2 failed
2a. "No targets accepted item [item] into slot 0"
2b. "Dropped 0 items"Expected Results:
The ominous_item_spawner and the item it drops change to dirt (or whatever is set)This is likely due to the fact that ominous item spawners store their item under "item" instead of "Item" with a capital 'I' like other entities do
Ominous Item Spawners store their item nbt under "item" likely causing /item and /loot replace to be unable to affect them in any slot, the "contents" slot included, as other entities store their item nbt under "Item" capitalized (item, item_frame, etc)
Steps to Reproduce:
1. /summon ominous_item_spawner ~ ~ ~ {spawn_item_after_ticks:50,item:{id:"stone",count:1}}
2a. /item replace entity @n[type=ominous_item_spawner] contents with dirt
2b. /loot replace entity @n[type=ominous_item_spawner] contents loot blocks/dirtObserved Results:
The ominous_item_spawner and the item it drops remain stone; the commands in step 2 failed
2a. "No targets accepted item [item] into slot 0"
2b. "Dropped 0 items"Expected Results:
The ominous_item_spawner and the item it drops change to dirt (or whatever is set)This is likely due to the fact that ominous item spawners store their item under "item" instead of "Item" with a capital 'I' like other entities do
Ominous Item Spawners store their item nbt under "item" likely causing /item and /loot replace to be unable to affect them in any slot, the "contents" slot included, as other entities store their item nbt under "Item" capitalized (item, item_frame, etc)
Steps to Reproduce:
1. /summon ominous_item_spawner ~ ~ ~ {spawn_item_after_ticks:50,item:{id:"stone",count:1}}
2a. /item replace entity @n[type=ominous_item_spawner] contents with dirt
2b. /loot replace entity @n[type=ominous_item_spawner] contents loot blocks/dirtObserved Results:
The ominous_item_spawner and the item it drops remain stone; the commands in step 2 failed
2a. "No targets accepted item [item] into slot 0"
2b. "Dropped 0 items"Expected Results:
The ominous_item_spawner and the item it drops change to dirt (or whatever is set)This is likely due to the fact that ominous item spawners store their item under "item" instead of "Item" with a capital 'I' like other entities do
Ominous Item Spawners store their item nbt under "item" likely causing /item and /loot replace to be unable to affect them in any slot, the "contents" slot included, as other entities store their item nbt under "Item" capitalized (item, item_frame, etc)
Steps to Reproduce:
1. /summon ominous_item_spawner ~ ~ ~ {spawn_item_after_ticks:50,item:{id:"stone",count:1}}
2a. /item replace entity @n[type=ominous_item_spawner] contents with dirt
2b. /loot replace entity @n[type=ominous_item_spawner] contents loot blocks/dirt
2c. /execute if items entity @n[type=ominous_item_spawner] contents stoneObserved Results:
The ominous_item_spawner and the item it drops remain stone; the commands in step 2 failed
2a. "No targets accepted item [item] into slot 0"
2b. "Dropped 0 items"
2c. "Test failed"Expected Results:
2a-b. The ominous_item_spawner and the item it drops change to dirt (or whatever is set)
2c. "Test passed"While "contents" is the expected slot for this entity's nbt, the same result occurs with every other slot specifiable
This is overall behavior likely due to the fact that ominous item spawners store their item under "item" instead of "Item" with a capital 'I' like other entities do
Ominous Item Spawners store their item nbt under "item" likely causing /item and /loot replace to be unable to affect them in any slot, the "contents" slot included, as other entities store their item nbt under "Item" capitalized (item, item_frame, etc)
Steps to Reproduce:
1. /summon ominous_item_spawner ~ ~ ~ {spawn_item_after_ticks:50,item:{id:"stone",count:1}}
2a. /item replace entity @n[type=ominous_item_spawner] contents with dirt
2b. /loot replace entity @n[type=ominous_item_spawner] contents loot blocks/dirt
2c. /execute if items entity @n[type=ominous_item_spawner] contents stoneObserved Results:
The ominous_item_spawner and the item it drops remain stone; the commands in step 2 failed
2a. "No targets accepted item [item] into slot 0"
2b. "Dropped 0 items"
2c. "Test failed"Expected Results:
2a-b. The ominous_item_spawner and the item it drops change to dirt (or whatever is set)
2c. "Test passed"While "contents" is the expected slot for this entity's nbt, the same result occurs with every other slot specifiable
This is overall behavior likely due to the fact that ominous item spawners store their item under "item" instead of "Item" with a capital 'I' like other entities do
The knockback_resistance attribute and the explosion_knockback_resistance attribute display differently in their descriptions: despite both being a % 0-1, knockback_resistance displays as multiplied by 10 whereas explosion_knockback_resistance displays normally as a decimal
Steps to Reproduce:
1. /give @s netherite_chestplate[enchantments=\\{levels:{"blast_protection":1}}]2. Observe item description
3. Equip and run :
/attribute @s minecraft:generic.knockback_resistance get
/attribute @s minecraft:generic.explosion_knockback_resistance get
Observed Behavior:
knockback_resistance displays multiplied by 10
explosion_knockback_resistance displays as decimal unmultipliedExpected Behavior:
knockback_resistance displays multiplied by 10
explosion_knockback_resistance displays multiplied by 10
OR
knockback_resistance displays as decimal
explosion_knockback_resistance displays as decimal
OR
knockback_resistance displays as percentage
explosion_knockback_resistance displays as percentagePhotos: (all with more explosion_knockback_resistance than knockback_resistance)
Netherite Chestplate providing 0.10 knockback_resistance and 0.15 explosion_knockback_resistance
Especially confusing when custom attributes amounts are involved, example with 0.141 knockback_resistance and 0.16 explosion_knockback_resistance
The knockback_resistance attribute and the explosion_knockback_resistance attribute display differently in their descriptions: despite both being a % 0-1, knockback_resistance displays as multiplied by 10 whereas explosion_knockback_resistance displays normally as a decimal
Steps to Reproduce:
1. /give @s netherite_chestplate[enchantments=\\{levels:{"blast_protection":1}}]2. Observe item description
3. Equip and run :
/attribute @s minecraft:generic.knockback_resistance get
/attribute @s minecraft:generic.explosion_knockback_resistance get
Observed Behavior:
knockback_resistance displays multiplied by 10
explosion_knockback_resistance displays as decimal unmultipliedExpected Behavior:
knockback_resistance displays multiplied by 10
explosion_knockback_resistance displays multiplied by 10
OR
knockback_resistance displays as decimal
explosion_knockback_resistance displays as decimal
OR
knockback_resistance displays as percentage
explosion_knockback_resistance displays as percentagePhotos: (all with more explosion_knockback_resistance than knockback_resistance)
Netherite Chestplate providing 0.10 knockback_resistance and 0.15 explosion_knockback_resistance
Especially confusing when custom attributes amounts are involved, example with 0.141 knockback_resistance and 0.16 explosion_knockback_resistance
The knockback_resistance attribute and the explosion_knockback_resistance attribute display differently in their descriptions: despite both being a % 0-1, knockback_resistance displays as multiplied by 10 whereas explosion_knockback_resistance displays normally as a decimal
Steps to Reproduce:
1. /give @s netherite_chestplate[enchantments=\\\{levels:{"blast_protection":1}}]2. Observe item description
3. Equip and run :
/attribute @s minecraft:generic.knockback_resistance get
/attribute @s minecraft:generic.explosion_knockback_resistance get
Observed Behavior:
knockback_resistance displays multiplied by 10
explosion_knockback_resistance displays as decimal unmultiplied
Both attributes use the same decimal scale internallyExpected Behavior:
knockback_resistance displays multiplied by 10
explosion_knockback_resistance displays multiplied by 10
OR
knockback_resistance displays as decimal
explosion_knockback_resistance displays as decimal
OR
knockback_resistance displays as percentage
explosion_knockback_resistance displays as percentage
Photos: (all with more explosion_knockback_resistance than knockback_resistance)
Netherite Chestplate providing 0.10 knockback_resistance and 0.15 explosion_knockback_resistance
Especially confusing when custom attributes amounts are involved, example with 0.141 knockback_resistance and 0.16 explosion_knockback_resistance
The knockback_resistance attribute and the explosion_knockback_resistance attribute display differently in their descriptions: despite both being a % 0-1, knockback_resistance displays as multiplied by 10 whereas explosion_knockback_resistance displays normally as a decimal
Steps to Reproduce:
1. /give @s netherite_chestplate[enchantments=\\\\{levels:{"blast_protection":1}}]2. Observe item description
3. Equip and run :
/attribute @s minecraft:generic.knockback_resistance get
/attribute @s minecraft:generic.explosion_knockback_resistance get
Observed Behavior:
knockback_resistance displays multiplied by 10
explosion_knockback_resistance displays as decimal unmultiplied
Both attributes use the same decimal scale internallyExpected Behavior:
knockback_resistance displays multiplied by 10
explosion_knockback_resistance displays multiplied by 10
OR
knockback_resistance displays as decimal
explosion_knockback_resistance displays as decimal
OR
knockback_resistance displays as percentage
explosion_knockback_resistance displays as percentage
Photos: (all with more explosion_knockback_resistance than knockback_resistance)
Netherite Chestplate providing 0.10 knockback_resistance and 0.15 explosion_knockback_resistance
Especially confusing when custom attributes amounts are involved, example with 0.141 knockback_resistance and 0.16 explosion_knockback_resistance
Similar issue order naming issue with certain savanna village street structures and terminators
Still present 1.20.6
Can confirm in 1.21.1 with marker entities
Can confirm 1.21.4