When the player enters a dialog while they are in a GUI, and then said GUI is forcibly closed, the dialog is also forcibly closed.
This behavior has some advantages, namely for the case where it is desired to replace a block or entity’s GUI with a dialog (since the dialog will automatically disappear if the block or entity is destroyed). However, there are surely cases where a datapack developer would like to show the player a dialog and assume that it will remain open until the player either dies, changes dimensions or performs a manual action such as clicking a button on the dialog, pressing Escape or quitting to the title screen. As an example, consider a server event where a dialog is shown to enable players to vote on which minigame they want to play– a player who is shown this dialog at the instant the villager they are trading with is slain by a zombie may never see it and assume that the vote system was simply bugged.
To reproduce
Recreate the setup below, with the trapped chest at the west (-X) end.
The first impulse command block (on the right) has the command
dialog show @p {type:"minecraft:multi_action",title:"Some dialog",actions:[{label:":)"}],pause:false}
The second one has the command
setblock ~-4 ~ ~ air
And the chain command block on top of it has the command
setblock ~-4 ~-1 ~ minecraft:trapped_chest[facing=north]
Then open the trapped chest.
Observed result
The shown dialog is closed immediately
Expected result
The shown dialog would remain open
Note
My particular use case is that I want to replace the enchanting table’s GUI with a dialog which allows players to randomly enchant their enchantable gear. I would of course prefer to use a data-driven GUI, but it would take some work for Mojang to implement those. Until they exist, a simpler solution for this sort of functionality would be to allow players to put a boolean argument at the end of their dialog command to specify whether the player’s existing GUI should be closed when the dialog is opened. This would not only make the dialog disappear if the block is destroyed, but also make it so that the player is not returned to the block’s GUI when they close the dialog. At present I need to set can_close_with_escape
to false, detect when the dialog is closed, and replace the enchanting table with a light block and block display for 2 ticks so that its GUI is forcibly closed- if this issue were fixed (without implementing my suggestion), I would have to manually check whether the block has been destroyed and close the dialog if so, but I would be able to destroy the dialog when the player interacts with the enchantment table rather than when they close the dialog, so the dialog could be made escapable. So ultimately a clean fix may be better for me than the current behavior, but having that extra argument would be really handy.
Attachments
Comments 0
No comments.