tholleman
- tholleman
- JIRAUSER540919
- Europe/Stockholm
- Yes
- No
What Should Happen
The `execute on owner` subcommand should select the owner of a horse, donkey, or mule
Steps to Reproduce
- Spawn in and tame a horse
- Keep riding the horse
- Run the command /execute on vehicle on owner run say I own this horse{}
- The chat will not display anything
Note that this behaviour shouldn't be expected from camels, skeleton horses, nor zombie horses. Those don't have the owner tag that the others do
It's possible to create an advancement that's granted when a player enchants items. A condition can be added to that trigger that qualifies how many levels the player should use before granting the advancement. However, setting this to 30 levels will not work since only 3 levels are actually removed from the player.
I can't be sure about the history but I think that this condition has been kept the same after changing the enchanting system in 1.8. Back then, all levels would be removed which would make this condition much more useful.
Here's an example advancement that I would expect to work:
{{}
{{ "display": {}}
{{ "icon": {}}
{{ "item": "minecraft:bookshelf",}}
{{ "nbt": "{Enchantments:[{}]}"}}
{{ },}}
{{ "title": "Artificer",}}
{{ "description": "Enchant an item at level 30"}}
{{ },}}
{{ "parent": "minecraft:story/enchant_item",}}
{{ "criteria": {}}
{{ "enchanted_item_30": {}}
{{ "trigger": "minecraft:enchanted_item",}}
{{ "conditions": {}}
{{ "levels": 30}}
{{{{ }}}}}{{{{}}}}}
{{{{ }}}}}
{}}I've attached a datapack with this advancement to test for yourself.
It's possible to create an advancement that's granted when a player enchants items. A condition can be added to that trigger that qualifies how many levels the player should use before granting the advancement. However, setting this to 30 levels will not work since only 3 levels are actually removed from the player.
I can't be sure about the history but I think that this condition has been kept the same after changing the enchanting system in 1.8. Back then, all levels would be removed which would make this condition much more useful.
Here's an example advancement that I would expect to work:
{{{
{ "levels": 30 }
"display": {
"icon": {
"item": "minecraft:bookshelf",
"nbt": "{Enchantments:[{}]}"
},
"title": "Artificer",
"description": "Enchant an item at level 30",
"frame": "task",
"show_toast": true,
"announce_to_chat": true,
"hidden": false
},
"parent": "minecraft:story/enchant_item",
"criteria": {
"requirement": {
"trigger": "minecraft:enchanted_item",
"conditions":}
}
}}}I've attached a datapack with this advancement to test for yourself.
It's possible to create an advancement that's granted when a player enchants items. A condition can be added to that trigger that qualifies how many levels the player should use before granting the advancement. However, setting this to 30 levels will not work since only 3 levels are actually removed from the player.
I can't be sure about the history but I think that this condition has been kept the same after changing the enchanting system in 1.8. Back then, all levels would be removed which would make this condition much more useful.
Here's an example advancement that I would expect to work:
{
{{{
"display": {
"icon": {
"item": "minecraft:bookshelf",
"nbt": "{Enchantments:[{}]}"
},
"title": "Artificer",
"description": "Enchant an item at level 30",
"frame": "task",
"show_toast": true,
"announce_to_chat": true,
"hidden": false
},
"parent": "minecraft:story/enchant_item",
"criteria": {
"requirement": {
"trigger": "minecraft:enchanted_item",
"conditions":"levels": 30}
}
}
}}}I've attached a datapack with this advancement to test for yourself.
It's possible to create an advancement that's granted when a player enchants items. A condition can be added to that trigger that qualifies how many levels the player should use before granting the advancement. However, setting this to 30 levels will not work since only 3 levels are actually removed from the player.
I can't be sure about the history but I think that this condition has been kept the same after changing the enchanting system in 1.8. Back then, all levels would be removed which would make this condition much more useful.
Here's an example advancement that I would expect to work:
{
{ "levels": 30 }
"display": {
"icon": {
"item": "minecraft:bookshelf",
"nbt": "{Enchantments:[{}]}"
},
"title": "Artificer",
"description": "Enchant an item at level 30",
"frame": "task",
"show_toast": true,
"announce_to_chat": true,
"hidden": false
},
"parent": "minecraft:story/enchant_item",
"criteria": {
"requirement": {
"trigger": "minecraft:enchanted_item",
"conditions":}
}
}I've attached a datapack with this advancement to test for yourself.
It's possible to create an advancement that's granted when a player enchants items. A condition can be added to that trigger that qualifies how many levels the player should use before granting the advancement. However, setting this to 30 levels will not work since only 3 levels are actually removed from the player.
I can't be sure about the history but I think that this condition has been kept the same after changing the enchanting system in 1.8. Back then, all levels would be removed which would make this condition much more useful.
Here's an example advancement that I would expect to work:
{{{
{ "levels": 30 }
"display": {
"icon": {
"item": "minecraft:bookshelf",
"nbt": "{Enchantments:[{}]}"
},
"title": "Artificer",
"description": "Enchant an item at level 30",
"frame": "task",
"show_toast": true,
"announce_to_chat": true,
"hidden": false
},
"parent": "minecraft:story/enchant_item",
"criteria": {
"requirement": {
"trigger": "minecraft:enchanted_item",
"conditions":}
}
}}}I've attached a datapack with this advancement to test for yourself.
It's possible to create an advancement that's granted when a player enchants items. A condition can be added to that trigger that qualifies how many levels the player should use before granting the advancement. However, setting this to 30 levels will not work since only 3 levels are actually removed from the player.
I can't be sure about the history but I think that this condition has been kept the same after changing the enchanting system in 1.8. Back then, all levels would be removed which would make this condition much more useful.
Here's an example advancement that I would expect to work:
{
{{{
"display": {
"icon": {
"item": "minecraft:bookshelf",
"nbt": "{Enchantments:[{}]}"
},
"title": "Artificer",
"description": "Enchant an item at level 30",
"frame": "task",
"show_toast": true,
"announce_to_chat": true,
"hidden": false
},
"parent": "minecraft:story/enchant_item",
"criteria": {
"requirement": {
"trigger": "minecraft:enchanted_item",
"conditions":"levels": 30}
}
}
}}}I've attached a datapack with this advancement to test for yourself.
It's possible to create an advancement that's granted when a player enchants items. A condition can be added to that trigger that qualifies how many levels the player should use before granting the advancement. However, setting this to 30 levels will not work since only 3 levels are actually removed from the player.
I can't be sure about the history but I think that this condition has been kept the same after changing the enchanting system in 1.8. Back then, all levels would be removed which would make this condition much more useful.
Here's an example advancement that I would expect to work:
{
{ "levels": 30 }
"display": {
"icon": {
"item": "minecraft:bookshelf",
"nbt": "{Enchantments:[{}]}"
},
"title": "Artificer",
"description": "Enchant an item at level 30",
"frame": "task",
"show_toast": true,
"announce_to_chat": true,
"hidden": false
},
"parent": "minecraft:story/enchant_item",
"criteria": {
"requirement": {
"trigger": "minecraft:enchanted_item",
"conditions":}
}
}I've attached a datapack with this advancement to test for yourself.
It's possible to create an advancement that's granted when a player enchants items. A condition can be added to that trigger that qualifies how many levels the player should use before granting the advancement. However, setting this to 30 levels will not work since only 3 levels are actually removed from the player.
I can't be sure about the history but I think that this condition has been kept the same after changing the enchanting system in 1.8. Back then, all levels would be removed which would make this condition much more useful.
Here's an example advancement that I would expect to work:
{
{ "levels": 30 }
"display": {
"icon": {
"item": "minecraft:bookshelf",
"nbt": "{Enchantments:[{}]}"
},
"title": "Artificer",
"description": "Enchant an item at level 30",
"frame": "task",
"show_toast": true,
"announce_to_chat": true,
"hidden": false
},
"parent": "minecraft:story/enchant_item",
"criteria": {
"requirement": {
"trigger": "minecraft:enchanted_item",
"conditions":}
}
}I've attached a datapack with this advancement to test for yourself.
When a mob transforms into another mob (ex. zombie villager → villager, mooshroom → cow), it loses all scores set with /scoreboard
Possibly related to
MC-88967When a mob transforms into another mob (ex. zombie villager → villager, mooshroom → cow), it loses all scores set with /scoreboard
Steps to reproduce:
- Create a scoreboard
/scoreboard objectives add test dummy
- Summon a villager
- Give the villager a score
/scoreboard players add @e[type=minecraft:villager] test 1
- Summon a zombie and let the villager be converted
/difficulty hard
- Get the scores of the new zombie villager
/scoreboard players list @e[type=minecraft:zombie_villager, sort=nearest, limit=1]
- Expect the zombie villager to have the test score of 1 and be disappointed
Possibly related to
MC-88967
When a mob transforms into another mob (ex. zombie villager → villager, mooshroom → cow), it loses all scores set with /scoreboard
Steps to reproduce:
- Create a scoreboard
/scoreboard objectives add test dummy
- Summon a villager
- Give the villager a score
/scoreboard players add @e[type=minecraft:villager] test 1
- Summon a zombie and let the villager be converted
/difficulty hard /time set midnight /summon minecraft:zombie
- Get the scores of the new zombie villager
/scoreboard players list @e[type=minecraft:zombie_villager, sort=nearest, limit=1]
- Expect the zombie villager to have the test score of 1 and be disappointed
Possibly related to
MC-88967
When a mob transforms into another mob (ex. zombie villager → villager, mooshroom → cow), it loses all scores set with /scoreboard
Steps to reproduce:
- Create a scoreboard
/scoreboard objectives add test dummy
- Summon a villager
- Give the villager a score
/scoreboard players add @e[type=minecraft:villager] test 1
- Summon a zombie and let the villager be converted
/difficulty hard /time set midnight /summon minecraft:zombie
- Get the scores of the new zombie villager
/scoreboard players list @e[type=minecraft:zombie_villager, sort=nearest, limit=1]
- Expect the zombie villager to have the test score of 1 and be disappointed
Possibly related to
MC-88967When a mob transforms into another mob (ex. zombie villager → villager, mooshroom → cow), it loses all scores set with /scoreboard
Steps to reproduce:
- Create a scoreboard
/scoreboard objectives add test dummy- Summon a villager
- Give the villager a score
/scoreboard players add @e[type=minecraft:villager] test 1- Summon a zombie and let the villager be converted
/difficulty hard /time set midnight /summon minecraft:zombie- Get the scores of the new zombie villager
/scoreboard players list @e[type=minecraft:zombie_villager, sort=nearest, limit=1]- Expect the zombie villager to have the test score of 1 and be disappointed
Possibly related to
MC-88967
I've included a minimal datapack that will cook fish caught by a fishing rod when the fishing rod has flame. This datapack will work in 1.20.6 but stopped working in 24w18a. It will now also cook the fish if the rod is enchanted with lure (or any other enchantment).
Steps to verify the datapack is working:
- Give yourself an unenchanted fishing rod and catch a fish
- Do the same with a fishing rod with lure 3
/give @s minecraft:fishing_rod[minecraft:enchantments={"minecraft:flame":1}]
- Catch a fish and see that it is indeed cooked this time
Steps to reproduce the bug:
- Upgrade the world to 24w18a
- Catch an uncooked fish with the unenchanted rod
- Catch a cooked fish with the flame fishing rod
- Catch a cooked fish with the lure fishing rod
Step 4 is the bug, it should have worked just like 1.20.6
This may be only the case for fishing. Enderchests still drop correctly with and without silk touch
I've included a minimal datapack that will cook fish caught by a fishing rod when the fishing rod has flame. This datapack will work in 1.20.6 but stopped working in 24w18a. It will now also cook the fish if the rod is enchanted with lure (or any other enchantment).
Steps to verify the datapack is working:
- Give yourself an unenchanted fishing rod and catch a fish
- Do the same with a fishing rod with lure 3
/give @s minecraft:fishing_rod[minecraft:enchantments={"minecraft:flame":1}] Catch a fish and see that it is indeed cooked this timeSteps to reproduce the bug:
- Upgrade the world to 24w18a
- Catch an uncooked fish with the unenchanted rod
- Catch a cooked fish with the flame fishing rod
- Catch a cooked fish with the lure fishing rod
Step 4 is the bug, it should have worked just like 1.20.6
This may be only the case for fishing. Enderchests still drop correctly with and without silk touch
I've included a minimal datapack that will cook fish caught by a fishing rod when the fishing rod has flame. This datapack will work in 1.20.6 but stopped working in 24w18a. It will now also cook the fish if the rod is enchanted with lure (or any other enchantment).
Steps to verify the datapack is working:
- Give yourself an unenchanted fishing rod and catch a fish
- Do the same with a fishing rod with lure 3
/give @s minecraft:fishing_rod[minecraft:enchantments={"minecraft:flame":1}] Catch a fish and see that it is indeed cooked this timeSteps to reproduce the bug:
- Upgrade the world to 24w18a
- Catch an uncooked fish with the unenchanted rod
- Catch a cooked fish with the flame fishing rod
- Catch a cooked fish with the lure fishing rod
Step 4 is the bug, it should have worked just like 1.20.6
This may be only the case for fishing. Enderchests still drop correctly with and without silk touch
I've included a minimal datapack that will cook fish caught by a fishing rod when the fishing rod has flame. This datapack will work in 1.20.6 but stopped working in 24w18a. It will now also cook the fish if the rod is enchanted with lure (or any other enchantment).
Steps to verify the datapack is working:
- Give yourself an unenchanted fishing rod and catch a fish
- Do the same with a fishing rod with lure 3
/give @s minecraft:fishing_rod[minecraft:enchantments={"minecraft:flame":1}
- Catch a fish and see that it is indeed cooked this time
Steps to reproduce the bug:
- Upgrade the world to 24w18a
- Catch an uncooked fish with the unenchanted rod
- Catch a cooked fish with the flame fishing rod
- Catch a cooked fish with the lure fishing rod
Step 4 is the bug, it should have worked just like 1.20.6
This may be only the case for fishing. Enderchests still drop correctly with and without silk touch
I've included a minimal datapack that will cook fish caught by a fishing rod when the fishing rod has flame. This datapack will work in 1.20.6 but stopped working in 24w18a. It will now also cook the fish if the rod is enchanted with lure (or any other enchantment).
Steps to verify the datapack is working:
- Give yourself an unenchanted fishing rod and catch a fish
- Do the same with a fishing rod with lure 3
/give @s minecraft:fishing_rod[minecraft:enchantments={"minecraft:flame":1}
- Catch a fish and see that it is indeed cooked this time
Steps to reproduce the bug:
- Upgrade the world to 24w18a
- Catch an uncooked fish with the unenchanted rod
- Catch a cooked fish with the flame fishing rod
- Catch a cooked fish with the lure fishing rod
Step 4 is the bug, it should have worked just like 1.20.6
This may be only the case for fishing. Enderchests still drop correctly with and without silk touch
I've included a minimal datapack that will cook fish caught by a fishing rod when the fishing rod has flame. This datapack will work in 1.20.6 but stopped working in 24w18a. It will now also cook the fish if the rod is enchanted with lure (or any other enchantment).
Steps to verify the datapack is working:
- Give yourself an unenchanted fishing rod and catch a fish
- Do the same with a fishing rod with lure 3
/give @s minecraft:fishing_rod[minecraft:enchantments={"minecraft:flame":1}- Catch a fish and see that it is indeed cooked this time
Steps to reproduce the bug:
- Upgrade the world to 24w18a
- Catch an uncooked fish with the unenchanted rod
- Catch a cooked fish with the flame fishing rod
- Catch a cooked fish with the lure fishing rod
Step 4 is the bug, it should have worked just like 1.20.6
This may be only the case for fishing. Enderchests still drop correctly with and without silk touch
I've included a minimal datapack that will cook fish caught by a fishing rod when the fishing rod has flame. This datapack will work in 1.20.6 but stopped working in 24w18a. It will now also cook the fish if the rod is enchanted with lure (or any other enchantment).
Steps to verify the datapack is working:
- Give yourself an unenchanted fishing rod and catch a fish
- Do the same with a fishing rod with lure 3
/give @s minecraft:fishing_rod[minecraft:enchantments={"minecraft:flame":1}- Catch a fish and see that it is indeed cooked this time
Steps to reproduce the bug:
- Upgrade the world to 24w18a
- Catch an uncooked fish with the unenchanted rod
- Catch a cooked fish with the flame fishing rod
- Catch a cooked fish with the lure fishing rod
Step 4 is the bug, it should have worked just like 1.20.6
This may be only the case for fishing. Enderchests still drop correctly with and without silk touch
I've included a minimal datapack that will cook fish caught by a fishing rod when the fishing rod has flame. This datapack will work in 1.20.6 but stopped working in 24w18a. It will now also cook the fish if the rod is enchanted with lure (or any other enchantment).
Steps to verify the datapack is working:
- Install the datapack
- Give yourself an unenchanted fishing rod and catch a fish
- Do the same with a fishing rod with lure 3
/give @s minecraft:fishing_rod[minecraft:enchantments={"minecraft:flame":1}
- Catch a fish and see that it is indeed cooked this time
Steps to reproduce the bug:
- Upgrade the world to 24w18a
- Catch an uncooked fish with the unenchanted rod
- Catch a cooked fish with the flame fishing rod
- Catch a cooked fish with the lure fishing rod
Step 4 is the bug, it should have worked just like 1.20.6
This may be only the case for fishing. Enderchests still drop correctly with and without silk touch
I've included a minimal datapack that will cook fish caught by a fishing rod when the fishing rod has flame. This datapack will work in 1.20.6 but stopped working in 24w18a. It will now also cook the fish if the rod is enchanted with lure (or any other enchantment).
Steps to verify the datapack is working:
- Install the datapack
- Give yourself an unenchanted fishing rod and catch a fish
- Do the same with a fishing rod with lure 3
/give @s minecraft:fishing_rod[minecraft:enchantments={"minecraft:flame":1}
- Catch a fish and see that it is indeed cooked this time
Steps to reproduce the bug:
- Upgrade the world to 24w18a
- Catch an uncooked fish with the unenchanted rod
- Catch a cooked fish with the flame fishing rod
- Catch a cooked fish with the lure fishing rod
Step 4 is the bug, it should have worked just like 1.20.6
This may be only the case for fishing. Enderchests still drop correctly with and without silk touch
I've included a minimal datapack that will cook fish caught by a fishing rod when the fishing rod has flame. This datapack will work in 1.20.6 but stopped working in 24w18a. It will now also cook the fish if the rod is enchanted with lure (or any other enchantment).
Steps to verify the datapack is working:
- Install the datapack
- Give yourself an unenchanted fishing rod and catch a fish
- Do the same with a fishing rod with lure 3
/give @s minecraft:fishing_rod[minecraft:enchantments={"minecraft:flame":1}- Catch a fish and see that it is indeed cooked this time
Steps to reproduce the bug:
- Upgrade the world to 24w18a
- Catch an uncooked fish with the unenchanted rod
- Catch a cooked fish with the flame fishing rod
- Catch a cooked fish with the lure fishing rod
Step 4 is the bug, it should have worked just like 1.20.6
This may be only the case for fishing. Enderchests still drop correctly with and without silk touch
I've included a datapack that should give a fishing bobber visual fire after it is spawned. This is done with a custom enchantment that runs a function when a projectile is spawned.
Steps to reproduce
- Install the datapack
- Give yourself a fishing rod
/enchant @s minecraft:grill
- Cast the rod and see that it isn't on fire
You can see that the enchantment does indeed work by trying it on a bow
/give @s bow[minecraft:enchantments={"minecraft:grill":1}]
I've included a datapack that should give a fishing bobber visual fire after it is spawned. This is done with a custom enchantment that runs a function when a projectile is spawned.
Steps to reproduce
- Install the datapack
- Give yourself a fishing rod
/enchant @s minecraft:grill- Cast the rod and see that it isn't on fire
You can see that the enchantment does indeed work by trying it on a bow
/give @s bow[minecraft:enchantments={"minecraft:grill":1}]



The issue described in
MCL-14797is not the same. The issues are with different files. However, it is possible that the underlying cause is the same.This issue has been fixed for Linux. I can now see the patch notes for 21w44a as well as Pre-Release 1.
Yes, the issue still persists in version Linux 5.13.0-30-generic 2.2.11106 on Ubuntu 20.04.4 LTS
Here are the steps to reproduce as shown in the video:
I should add that the video is edited to speed up the loading time. There is no bug with the animation.
That's odd, I just restarted minecraft and now I can't reproduce it. Same 2 worlds I tried it in. I still have the xp I gained though.
Let's not start a discussion in these comments. Moesh has said this should be a feature request so I made one here I hope everyone who wants to see it added will vote for this feature.
Seems it's still pending approval. Just wait a day. I might post an update here once it gets approved as well
This also happens with markers which is even weirder since markers riding entities worked perfectly before this snapshot.
It's been a while and this is still unresolved. For anyone who's also experiencing this issue, you can set the files to read-only as a temporary workaround.
cd ~/.minecraft
sed -i 's/"fullscreen" : false/"fullscreen" : true/' window_settings_launcher.conf window_settings_log.conf
chmod 444 window_settings_launcher.conf window_settings_log.conf
I recommend following this issue if you're gonna do this. Changing the file rights back after this issue is fixed could help avoid issues in the future.
Hi!
The game starts fine. It's just inaccurate to say that the game is installing. It might just be a string that needs to be changed or there might be a bug that makes the launcher think that there's an update.
Is this still a bug considering the mob attack reach changes in 23w33a?
The same will happen to custom stack sized knowledge books.
/give @s minecraft:knowledge_book[minecraft:recipes=["minecraft:acacia_boat"],minecraft:max_stack_size=64] 64
Using the knowledge book in survival will consume the entire stack instead of just one.
I guess the resolution should now be "fixed" since (+NBT) has been removed
The issue is that the predicate tests with component instead of predicates as mentioned in
MC-270707. There is no predicate for a lodestone_tracker but that probably makes this a feature request.I worked around it with a function that returns 1 or 0 based on the player data. I then used execute if function which was fine for my needs. That solution wouldn't work if you want to do this check in a json file
I commented this in
MC-269642but probably should have made a separate report.Still an issue in 1.20.5
This is unexpected behavior due to a problem in the game's code. This is a perfectly valid bug.
You can read more about what counts as a valid bug here
Saw this happen today in 1.20.6
Thanks, I've gotten too used to seeing warnings in the log when something goes wrong
Cool, thanks
Thanks for pointing it out. The function directory was plural.
I've confirmed the issue to still be in 1.21 Pre-Release 2
Was this supposed to be marked as invalid? "Working as intended" or "Won't fix" would make more sense.