Bedrock Forms

This is automatic. You author one menu; Java players get the chest, Bedrock players get the form. You only reach for the options below when you want to tune what the form looks like.

How a menu becomes a form

When a Bedrock viewer opens a menu, the engine picks a Cumulus form type to match its shape:

For a SimpleForm, the degradation is done for you: each item that binds at least one click action becomes a button carrying that item's name. Decorative tiles — the filler panes, blank borders, display-only info items — bind no action, so they are left off the form (a button that does nothing on tap would be meaningless). Tap a button and its action list runs exactly as a click would on Java.

When the chest is kept anyway: chest-only

Some menus can't be a form. A form is a flat list of buttons — it cannot display or edit real item stacks. So a menu that shows an inventory (the vault, the inventory viewer, a storage-style grid) stays a chest even for a Bedrock viewer.

The built-in storage menus already do this. For a custom menu that displays item stacks, set the flag yourself:

chest-only = true

With chest-only, a Bedrock viewer gets the chest GUI instead of a form. A menu that uses bottom-inventory is chest-only automatically, since its raw-slot geometry only makes sense in a chest.

An explicit form: the bedrock { } block

The automatic SimpleForm is a button list — it can't offer a dropdown, a slider or a text field. When you want those form-native controls, add a bedrock { } block. A Bedrock viewer then gets that explicit CustomForm; a Java viewer never sees it and keeps the chest.

title = "<gold>Warp Creator"
rows = 3

# The chest tiles a Java player sees:
items {
  # … your normal item map …
}

# The native form a Bedrock player sees instead:
bedrock {
  title = "Create a Warp"
  content = "Fill in the details, then submit."
  widgets = [
    { type = input,    name = warp-name, label = "Warp name", placeholder = "spawn", default = "" }
    { type = dropdown, name = category,  label = "Category",  options = ["Public", "Staff", "VIP"], default = 0 }
    { type = slider,   name = cost,      label = "Cost",      min = 0, max = 1000, step = 50, default = 100 }
    { type = toggle,   name = locked,    label = "Locked?",   default = false }
    { type = label,    text = "You can edit this later with /warp editor." }
  ]
  on-submit = [
    "console:uxmwarp create %warp-name% %cost%",
    "message:<green>Created warp %warp-name%."
  ]
}

Each value widget carries a name. When the player submits, its value is bound to a %name% placeholder — %warp-name%, %cost%, %locked% above — and the on-submit action list runs with those values in scope.

Widget types

Widget labels, the form title and content are verbatim MiniMessage (or @catalog.key), just like item names — they may hold placeholders and are resolved per open.

Graceful fallback

Everything degrades to something sensible:

• No Floodgate → the form path never engages; everyone gets the chest.
• chest-only → this menu is a chest for Bedrock viewers too.
• No bedrock { } block → the automatic SimpleForm/ModalForm degradation is used.
• A bedrock { } block → Bedrock viewers get that CustomForm; Java viewers ignore it.

You never end up with a broken menu — the worst case is a Bedrock player seeing the same chest a Java player would.

Next Steps

• Bedrock (Floodgate) — enabling Floodgate detection.
• Custom Menu Engine — the chest-only and bedrock keys in context.
• Actions & Requirements — what on-submit actions can do.