Marcelon1
- Marcelon1
- JIRAUSER732761
- Europe/Stockholm
- Yes
- No
MCPE-161450
MC-259379
When
executing the /saycommand as an entity, it's name is not displayed between the square brackets in chat. Instead it shows empty square brackets.
Player names work as expected.
Steps to Reproduce:
Execute the /say command as an entity that is not a player. For example:
/execute as @e[c=1, type=!player] run say test
When running /say with the experimental execute command as an entity, it's name is not displayed between the square brackets in chat. Instead it shows empty square brackets.
Player names work as expected.
Steps to Reproduce:
Execute the /say command as an entity that is not a player. For example:
/execute as @e[c=1, type=!player] run say test
When running /say with the experimental /execute command as an entity, it's name is not displayed between the square brackets in chat. Instead it shows empty square brackets.
Player names work as expected.
Steps to Reproduce:
Execute the /say command as an entity that is not a player. For example:
/execute as @e[c=1, type=!player] run say test
When running /say with the experimental /execute command as an entity, it's name is not displayed between the square brackets in chat. Instead it shows empty square brackets.
Player names aswell as mobs with a nametag work as expected.
Steps to Reproduce:
Execute the /say command as an entity that is not a player. For example:
/execute as @e[c=1, type=!player] run say test
say command executed as entity doesn't displayentityname in chat
When running /say
with the experimental /execute command as an entity, it's name is not displayed between the square brackets in chat. Instead it shows empty square brackets.
Player names aswell as mobs with a nametag work as expected.
Steps to Reproduce:
Execute the /say command as an entity that is not a player. For example:
/execute as @e[c=1, type=!player] run say test
When running /say with the experimental /execute command as an entity, it's name is not displayed between the square brackets in chat. Instead it shows empty square brackets.
Playernames aswell as mobs with a nametag work as expected.
Steps to Reproduce:
Execute the /say command as an entity that is not a player. For example:
/execute as @e[c=1, type=!player] run say test
@initiator in npc dialogs only works in /execute when used in the first subcommand. In the second, third, etc. subcommand it won't work. This only applies to @initiator and not @s, @a, etc.
Example:
/execute as @initiator run say hi This command works because @initiator is used in the first subcommand of /execute.
/execute align x as @initiator run say hi This command doesn't work because @initiator isn't in the first subcommand, so the command won't run as the initiator.
You can see this behaviour in the world attached. Try out the different buttons in the npc dialog.@initiator in npc dialogs only works in /execute when used in the first subcommand. In the second, third, etc. subcommand it won't work. This only applies to @initiator and not @s, @a, etc.
Example:
/execute as @initiator run say hi This command works because @initiator is used in the first subcommand of /execute.
/execute align x as @initiator run say hi This command doesn't work because @initiator isn't in the first subcommand, so the command won't run as the initiator.
You can see this behaviour in the world attached. Try out the different buttons in the npc dialog.
@initiator in npc dialogs only works in /execute when used in the first subcommand. In the second, third, etc. subcommand it won't work. This only applies to @initiator and not @s, @a, etc.
Example:
/execute as @initiator run say hi This command works because @initiator is used in the first subcommand of /execute.
/execute align x as @initiator run say hi This command doesn't work because @initiator isn't in the first subcommand, so the command won't run as the initiator.
You can see this behaviour in the world attached. Try out the different buttons in the npc dialog.@initiator in npc dialogs only works in /execute when used in the first subcommand. In the second, third, etc. subcommand it won't work. This only applies to @initiator and not @s, @a, etc.
Example:
/execute as @initiator run say hi This command works because @initiator is used in the first subcommand of /execute.
/execute align x as @initiator run say hi This command doesn't work because @initiator isn't in the first subcommand, so the command won't run as the initiator.
Expected behaviour: @initiator should be valid in every execute subcommand
You can see this behaviour in the world attached. Try out the different buttons in the npc dialog.
Cauldron watersometimes turns white when interacting with the worldCauldron water appears with the lava texture
The water inside cauldrons sometimes turns white when breaking blocks, placing blocks or interacting with blocks (such as doors) in the world. This happens very inconsistently.
Update in 1.20.0.25:
Water now doesn't flash white anymore, but constantly appears as the lava texture
test_world.mcworld
The /execute command doesn't work inside the on_open_commands, on_close_commands or as a button in dialogue json files that are opened with /dialogue. The command works everyhwere else including in a normal NPC dialogue that is configured ingame in creative mode.
Steps to reproduce:
- Open the attached world
- Click the button on the command block to open a test dialogue using /dialogue
- Click the "Execute Test" button in the dialogue
Expected results:
It should say "[NPC] open", "[NPC] button" and "[NPC] close" in chat because "/execute as @s run say ..." should be run when the dialogue opens, when the button is clicked and when the dialogue closes.
Observed results:
The execute commands in the dialogue won't trigger and it won't say "[NPC] open, "[NPC] button" or "[NPC] close" in chat.
When using the geometry.full_block geometry identifier to make a 16x16x16 block the
blockitem appears too small compared to vanilla blocks in the inventory. A custom geometry that contains a 16x16x16 cube is also affected. This makes custom blocks feel inconsistent and out of place in the inventory.Expected Behavior:
Custom blocks that use geometry.full_block or have a custom 16x16x16 geometry should be the same size in the inventory as vanilla blocks with the same proportions.
How to reproduce:
- Import the attached behavior pack
- Create a world with the behavior pack enabled
- Compare the item size of the custom block test:fake_planks with vanilla full blocks
Affects version 1.19.73 and preview version 1.19.80.24
I added a world where I experienced this issue
affects preview 1.20.0.25 and stable 1.19.83
Cauldron water quickly flashing white is no longer an issue as of Preview version 1.20.0.25. However water in cauldrons now appear as a dark lava texture in version 1.20.0.25 (see Cauldron_water_1.20.0.25.png attachment).