Sunroses
- tinzin
- tinzin
- America/Vancouver
- Yes
- No
MC-121921
Normal
(also affects 17w43b)
What I expected to happen was...: the function should run
What actually happened was...: "Unknown function: namespace:folder/function"Steps to Reproduce:
- Create a new world (or open an existing one) in 17w45b
- Create a "functions" folder in [world save]/data
- Create a "namespace" folder in [world save]/data/functions
- Create a file called "test.mcfunction" in [world save]/data/functions/namespace
- Add a command such as "say test" and save the file.
- Back in minecraft, run the command
"/reload".(note that in the case of invalid commands it still provides no feedback, even though it's supposed to display an error)- Run the command "/function namespace:test"
- Observe the output "Unknown function: namespace:test"
(also affects 17w43b)
What I expected to happen was...: the function should run
What actually happened was...: "Unknown function: namespace:folder/function"Steps to Reproduce:
- Create a new world (or open an existing one) in 17w45b
- Create a "functions" folder in [world save]/data
- Create a "namespace" folder in [world save]/data/functions
- Create a file called "test.mcfunction" in [world save]/data/functions/namespace
- Add a command such as "say test" and save the file.
- Back in minecraft, run the command /reload (note that in the case of invalid commands it still provides no feedback, even though it's supposed to display an error)
- Run the following command:
/function namespace:test- Observe the output:
Unknown function: namespace:test
it's saying i don't have access to that page, did they take it down or something
When a /item command conditional to a predicate (and/or possibly under other edge-case conditions?) modifies an item in the player's inventory, it will not visually update unless removed and replaced or otherwise forcibly updated,
Test case setup (a bit contrived, a simpler case can probably be constructed):
set the following data pack item modifier in a data pack using the "test" namespace as "spell_test.json":
[ { "function": "minecraft:set_components", "components": { "minecraft:consumable":{ "consume_seconds":0.7, "animation":"bow", "sound":"item.book.page_turn", "has_consume_particles":false, "on_consume_effects":[ {"type":"minecraft:apply_effects","effects":[ {"id":"minecraft:nausea","duration":10} ]}, {"type":"minecraft:play_sound","sound":"item.firecharge.use"} ] }, "minecraft:use_remainder": { "id":"minecraft:flow_banner_pattern", "components":{ "minecraft:custom_data":"{spell:1s}" } }, "minecraft:item_name": "{\"type\": \"text\",\"text\": \"Spell Test\"}", "minecraft:custom_data": "{spell:1s}" } } ]set the following predicate under the same namespace as "reset_spell_test.json":
{ "condition": "minecraft:entity_properties", "entity": "this", "predicate": { "slots": { "weapon.mainhand": { "items": "minecraft:flow_banner_pattern", "components": { "minecraft:custom_data": "{spell:1s}" } } } } }put the following in a repeating command block:
execute as @a[predicate=test:reset_spell_test] run item modify entity @s weapon.mainhand test:spell_testthen give yourself a flow banner pattern and run the following command:
/item modify entity @s weapon.mainhand test:spell_testthen switch to survival mode and use the item.
Expected result: Item resets itself to the same state (with the custom name "Spell Test", and usable with right click) after being consumed.
Actual result: Item returns to a default state after being consumed, and is generally not usable until the player removes it from their inventory and returns it in some way (picking it up inside the inventory is sufficient to update it). It's possible to confirm the item does have the correct data already using the "/data get" command, but the client demonstrably doesn't act like it does.
Unsure if the desync here is due to using a predicate, or because it runs on an item that has just been created with a use remainder, but either way it's a big problem for certain data pack use cases.
When a /item command modifies an item in the player's inventory that has just been replaced with a use_remainder component, it will not visually update unless removed and replaced or otherwise forcibly updated,
Test case setup (a bit contrived, a simpler case can probably be constructed):
set the following data pack item modifier in a data pack using the "test" namespace as "spell_test.json":
[ { "function": "minecraft:set_components", "components": { "minecraft:consumable":{ "consume_seconds":0.7, "animation":"bow", "sound":"item.book.page_turn", "has_consume_particles":false, "on_consume_effects":[ {"type":"minecraft:apply_effects","effects":[ {"id":"minecraft:nausea","duration":10} ]}, {"type":"minecraft:play_sound","sound":"item.firecharge.use"} ] }, "minecraft:use_remainder": { "id":"minecraft:flow_banner_pattern", "components":{ "minecraft:custom_data":"{spell:1s}" } }, "minecraft:item_name": "{\"type\": \"text\",\"text\": \"Spell Test\"}", "minecraft:custom_data": "{spell:1s}" } } ]set the following predicate under the same namespace as "reset_spell_test.json":
{ "condition": "minecraft:entity_properties", "entity": "this", "predicate": { "slots": { "weapon.mainhand": { "items": "minecraft:flow_banner_pattern", "components": { "minecraft:custom_data": "{spell:1s}" } } } } }put the following in a repeating command block:
execute as @a[predicate=test:reset_spell_test] run item modify entity @s weapon.mainhand test:spell_testthen give yourself a flow banner pattern and run the following command:
/item modify entity @s weapon.mainhand test:spell_testthen switch to survival mode and use the item.
Expected result: Item resets itself to the same state (with the custom name "Spell Test", and usable with right click) after being consumed.
Actual result: Item returns to a default state after being consumed, and is generally not usable until the player removes it from their inventory and returns it in some way (picking it up inside the inventory is sufficient to update it). It's possible to confirm the item does have the correct data already using the "/data get" command, but the client demonstrably doesn't act like it does.
Unsure if the desync here is due to using a predicate, or because it runs on an item that has just been created with a use remainder, but either way it's a big problem for certain data pack use cases.
/item modify doesn't always update the item on the client after use_remainder
When a /item command modifies an item in the player's inventory that has just been replaced with a use_remainder component, it will not visually update unless removed and replaced or otherwise forcibly updated,
Test case setup (a bit contrived, a simpler case can probably be constructed):
set the following data pack item modifier in a data pack using the "test" namespace as "spell_test.json":
[ { "function": "minecraft:set_components", "components": { "minecraft:consumable":{ "consume_seconds":0.7, "animation":"bow", "sound":"item.book.page_turn", "has_consume_particles":false, "on_consume_effects":[ {"type":"minecraft:apply_effects","effects":[ {"id":"minecraft:nausea","duration":10} ]}, {"type":"minecraft:play_sound","sound":"item.firecharge.use"} ] }, "minecraft:use_remainder": { "id":"minecraft:flow_banner_pattern", "components":{ "minecraft:custom_data":"{spell:1s}" } }, "minecraft:item_name": "{\"type\": \"text\",\"text\": \"Spell Test\"}", "minecraft:custom_data": "{spell:1s}" } } ]set the following predicate under the same namespace as "reset_spell_test.json":
{ "condition": "minecraft:entity_properties", "entity": "this", "predicate": { "slots": { "weapon.mainhand": { "items": "minecraft:flow_banner_pattern", "components": { "minecraft:custom_data": "{spell:1s}" } } } } }put the following in a repeating command block:
execute as @a[predicate=test:reset_spell_test] run item modify entity @s weapon.mainhand test:spell_testthe
n give yourself a flow banner pattern and run the following command:/item modify entity @s weapon.mainhand test:spell_testthen switch to survival mode and use the item.
Expected result: Item resets itself to the same state (with the custom name "Spell Test", and usable with right click) after being consumed.
Actual result: Item returns to a default state after being consumed, and is generally not usable until the player removes it from their inventory and returns it in some way (picking it up inside the inventory is sufficient to update it). It's possible to confirm the item does have the correct data already using the "/data get" command, but the client demonstrably doesn't act like it does.
Unsure if the desync here is due to using a predicate, or because it runs on an item that has just been created with a use remainder, but either way it's a big problem for certain data pack use cases.
When a /item command modifies an item in the player's inventory that has just been replaced with a use_remainder component, it will not visually update unless removed and replaced or otherwise forcibly updated,
Test case setup (a bit contrived, a simpler case can probably be constructed):
set the following data pack item modifier in a data pack using the "test" namespace as "spell_test.json":
[ { "function": "minecraft:set_components", "components": { "minecraft:consumable":{ "consume_seconds":0.7, "animation":"bow", "sound":"item.book.page_turn", "has_consume_particles":false, "on_consume_effects":[ {"type":"minecraft:apply_effects","effects":[ {"id":"minecraft:nausea","duration":10} ]}, {"type":"minecraft:play_sound","sound":"item.firecharge.use"} ] }, "minecraft:use_remainder": { "id":"minecraft:flow_banner_pattern", "components":{ "minecraft:custom_data":"{spell:1s}" } }, "minecraft:item_name": "{\"type\": \"text\",\"text\": \"Spell Test\"}", "minecraft:custom_data": "{spell:1s}" } } ]set the following predicate under the same namespace as "reset_spell_test.json":
{ "condition": "minecraft:entity_properties", "entity": "this", "predicate": { "slots": { "weapon.mainhand": { "items": "minecraft:flow_banner_pattern", "components": { "minecraft:custom_data": "{spell:1s}" } } } } }put the following in a repeating command block:
execute as @a[predicate=test:reset_spell_test] run item modify entity @s weapon.mainhand test:spell_test(the above can all be automated by downloading the attached data pack)
then give yourself a flow banner pattern and run the following command:
/item modify entity @s weapon.mainhand test:spell_testthen switch to survival mode and use the item.
Expected result: Item resets itself to the same state (with the custom name "Spell Test", and usable with right click) after being consumed.
Actual result: Item returns to a default state after being consumed, and is generally not usable until the player removes it from their inventory and returns it in some way (picking it up inside the inventory is sufficient to update it). It's possible to confirm the item does have the correct data already using the "/data get" command, but the client demonstrably doesn't act like it does.
Unsure if the desync here is due to using a predicate, or because it runs on an item that has just been created with a use remainder, but either way it's a big problem for certain data pack use cases.
When a /item command modifies an item in the player's inventory that has just been replaced with a use_remainder component, it will not visually update unless removed and replaced or otherwise forcibly updated,
Test case setup (a bit contrived, a simpler case can probably be constructed):
set the following data pack item modifier in a data pack using the "test" namespace as "spell_test.json":
[ { "function": "minecraft:set_components", "components": { "minecraft:consumable":{ "consume_seconds":0.7, "animation":"bow", "sound":"item.book.page_turn", "has_consume_particles":false, "on_consume_effects":[ {"type":"minecraft:apply_effects","effects":[ {"id":"minecraft:nausea","duration":10} ]}, {"type":"minecraft:play_sound","sound":"item.firecharge.use"} ] }, "minecraft:use_remainder": { "id":"minecraft:flow_banner_pattern", "components":{ "minecraft:custom_data":"{spell:1s}" } }, "minecraft:item_name": "{\"type\": \"text\",\"text\": \"Spell Test\"}", "minecraft:custom_data": "{spell:1s}" } } ]set the following predicate under the same namespace as "reset_spell_test.json":
{ "condition": "minecraft:entity_properties", "entity": "this", "predicate": { "slots": { "weapon.mainhand": { "items": "minecraft:flow_banner_pattern", "components": { "minecraft:custom_data": "{spell:1s}" } } } } }put the following in a repeating command block:
execute as @a[predicate=test:reset_spell_test] run item modify entity @s weapon.mainhand test:spell_test(the above can all be
automated by downloading the attached data pack)
then give yourself a flow banner pattern and run the following command:
/item modify entity @s weapon.mainhand test:spell_testthen switch to survival mode and use the item.
Expected result: Item resets itself to the same state (with the custom name "Spell Test", and usable with right click) after being consumed.
Actual result: Item returns to a default state after being consumed, and is generally not usable until the player removes it from their inventory and returns it in some way (picking it up inside the inventory is sufficient to update it). It's possible to confirm the item does have the correct data already using the "/data get" command, but the client demonstrably doesn't act like it does.
Unsure if the desync here is due to using a predicate, or because it runs on an item that has just been created with a use remainder, but either way it's a big problem for certain data pack use cases.
When a /item command modifies an item in the player's inventory that has just been replaced with a use_remainder component, it will not visually update unless removed and replaced or otherwise forcibly updated,
Test case setup (a bit contrived, a simpler case can probably be constructed):
set the following data pack item modifier in a data pack using the "test" namespace as "spell_test.json":
[ { "function": "minecraft:set_components", "components": { "minecraft:consumable":{ "consume_seconds":0.7, "animation":"bow", "sound":"item.book.page_turn", "has_consume_particles":false, "on_consume_effects":[ {"type":"minecraft:apply_effects","effects":[ {"id":"minecraft:nausea","duration":10} ]}, {"type":"minecraft:play_sound","sound":"item.firecharge.use"} ] }, "minecraft:use_remainder": { "id":"minecraft:flow_banner_pattern", "components":{ "minecraft:custom_data":"{spell:1s}" } }, "minecraft:item_name": "{\"type\": \"text\",\"text\": \"Spell Test\"}", "minecraft:custom_data": "{spell:1s}" } } ]set the following predicate under the same namespace as "reset_spell_test.json":
{ "condition": "minecraft:entity_properties", "entity": "this", "predicate": { "slots": { "weapon.mainhand": { "items": "minecraft:flow_banner_pattern", "components": { "minecraft:custom_data": "{spell:1s}" } } } } }put the following in a repeating command block:
execute as @a[predicate=test:reset_spell_test] run item modify entity @s weapon.mainhand test:spell_test(the above can all be bypassed by downloading the attached data pack)
then give yourself a flow banner pattern and run the following command:
/item modify entity @s weapon.mainhand test:spell_testthen switch to survival mode and use the item.
Expected result: Item resets itself to the same state (with the custom name "Spell Test", and usable with right click) after being consumed.
Actual result: Item returns to a default state after being consumed, and is generally not usable until the player removes it from their inventory and returns it in some way (picking it up inside the inventory is sufficient to update it). It's possible to confirm the item does have the correct data already using the "/data get" command, but the client demonstrably doesn't act like it does.
Unsure if the desync here is due to using a predicate, or because it runs on an item that has just been created with a use remainder, but either way it's a big problem for certain data pack use cases.
Sunroses No, it's not related, you just had an error in your function. (commenting here so that future readers don't think it's related)
can confirm commandblockoutput not working, gameLoopFunction could also be part of the issue that seems to be preventing functions from being found at all
i guess this should be marked as a duplicate of that then
i'm pretty sure i tried making a data pack and ran into the exact same issue
i fixed everything afaik and it's still not recognizing the functions??
the folder structure is
-datapacks
--pack
---data
----tinzin
-----functions
------roles.mcfunction
ah, it's just only showing the errors in the functions in the log output .-.
is that intended..?
okay, confirmed, valid functions in data packs work fine. whoops!
can confirm for 18w09a, crashed on /particle minecraft:dust 0 0 0 0 -1 5.1 20 .5 .1 .5 1 50 with the same error shown above
can confirm for 1.13.1
please fix
Please reconsider the "won't fix" assessment, this is a potential photosensitive epilepsy risk
someone who's good with minecraft code help me budget this my tree farm is dying
we've also experienced this, it seems to happen nearly at random but might be related to tabbing out of the game or using the settings menus or something..?
have encountered the same issue, can confirm
There's no reason it wouldn't affect literally every block, if we understand it correctly. The issue is in the code that calculates whether a player is "on" a block or not for the purposes of any effect relating to standing on a block.
This is a major bug but it's also likely an extremely nontrivial fix; not only would the devs need to change the code that calculates whether a player is standing on a given block, they'd also need to add code to handle any potentially conflicting effects (such as if a player is standing on both soul soil and honey blocks while wearing soul speed boots, for example). While this could absolutely be done, there's no super obvious answer for how to go about it. Personally, what we'd do is just have the effects stack, and cancel out if they conflict? But that also means they'd have to make sure standing on the line between two blocks with the same effect doesn't cause the effect to be doubled!!
I do hope mojang is at least discussing how to handle this, though. It seems like something very much worth prioritizing once other major bugs have been handled.
we suspect this relates to
MC-67.@violine1101 most likely, yes
we can do some more testing when we have the time.
Can confirm.
data pack added.