Opening and fallbacks
How every form opens, the keys they share, client limits, fallbacks as links and every way to open a menu.
All three forms open the same way, with the same keys.
| Screen attribute | Chest key, or 3D key under menu: | Does |
|---|---|---|
command, aliases | command, aliases (a list) | The commands that open it, installed on load and on /screensadmin reload. |
permission | permission | Who may open it. Without one, everybody. |
require, deny | require, deny | An expression checked before opening, and the lines run when it fails. Without deny, the player gets a no-permission message. |
fallback | fallback | The id of the menu a client gets when it cannot draw this one. |
min-client | min-client | The oldest client that gets this menu (1.21.4); older ones take the fallback. |
args | args (a list) | The words after the command, by name. |
on-open | on-open | Interaction lines run as it opens. |
Arguments
args="player" makes /stats Bob fill %player% in a chest or 3D menu and ${player} in a screen. An argument is letters, digits and _.:-, up to 64 characters; anything else, or too few words,
answers with the usage line. Commands are for players only.
Fallbacks are links, never copies
hub.html with fallback="hub_chest" opens as a screen, and a client that cannot draw screens gets menus/hub_chest.yml, which you wrote. The plugin never makes one for you.
- A fallback may have its own:
hub_3dgoes tohub, which goes tohub_chest. - A menu with no fallback tells such a client it does not work there.
- A chest menu is drawn by every client, so its
fallbackis never taken. - A player who chose chest windows in
/settingsalso takes the fallback of a screen or 3D menu that has one, unlessfollow-player-style: falseinconfig.yml. A menu with no fallback still opens. /screensadmin checknames a fallback that does not exist or leads in a circle.
Which clients can draw what: screens need Java 1.20.2 or newer (not Bedrock), 3D menus need Java 1.21.4 or newer, min-client can raise either. The importers write the chest menu and link it
for you; that is the only time a fallback is created, and it is the importer's output, not an automatic behaviour.
Ways to open a menu
| From | How |
|---|---|
| A command | The menu's command and aliases. |
| A screen | action="open shop", or open shop tab=food to set its state. |
| A chest or 3D click, a hologram, an NPC, a clickable block | Any ExyliaLib interaction line: [SCREEN] shop. |
| Another plugin's actions | exyliascreens:open shop. |
| Joining | open-on-join: hub in config.yml, after open-on-join-delay ticks. |
| A held item | open-items.yml. |
| Staff | /screensadmin open shop <player>. |
Opening goes through the menu's permission and requirement every time, whichever way it was reached.
Something missing on this page? Tell us on Discord