> For the complete documentation index, see [llms.txt](https://docs.myarc.icu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.myarc.icu/en/menu-configuration/menus/backend.md).

# Backend regions and click events

`backend` handles pointer and gaze interaction. Once you have arranged your button graphics and labels in `frontend`, placing a rectangular region at the matching coordinates in `backend` makes the button respond to clicks, hover events, and tooltips.

If you need a text input box, you can configure `type: Arcitx` in `backend` (see [Arcitx text input](/en/feature-configuration/arcitx.md)). If you want to move multiple click regions together, use `type: group` (see [Groups and reusable templates](/en/menu-configuration/menus/groups-templates.md)). Standard click regions do not need a `type` field.

## Region properties

```yaml
backend:
  greeting-area:
    x: 0
    y: -20
    width: 60
    height: 18
    priority: 1
    tooltip:
      - '&fWelcome Button'
      - '&7Right-click to say hello'
    update: 20
    actions:
      right: 'tell: &aHello, %player_name%!'
      shift-right: close
```

| Property          | Value and description                                                                                                                                                     | Default when omitted |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- |
| `x`, `y`          | Canvas coordinates of the region center, as finite numbers.                                                                                                               | `0`                  |
| `width`, `height` | Required width and height of the region. Must be numbers greater than `0`.                                                                                                | Required             |
| `priority`        | Integer priority. When two regions overlap on the canvas, the pointer hits the one with the higher `priority`; if tied, the region written earlier in the YAML file wins. | `0`                  |
| `tooltip`         | Tooltip text shown while hovering over the region, as a single string or a list of strings.                                                                               | Empty (no tooltip)   |
| `update`          | Refresh interval in ticks for placeholders inside the tooltip. Use a positive integer for periodic updates, or `-1` for no periodic updates. Cannot be `0`.               | `-1`                 |
| `condition`       | Condition expression string for the region. Determines whether clicks run `actions` or `deny`, and whether hover actions trigger.                                         | Unconditional        |
| `actions`         | Actions triggered on click when the condition passes (or when no condition is set).                                                                                       | Empty                |
| `deny`            | Actions triggered on click when `condition` is set and fails (single action or action list).                                                                              | Empty                |
| `on-hover`        | Actions or conditional action groups triggered when the pointer first enters the region.                                                                                  | Empty                |
| `on-leave`        | Actions or conditional action groups triggered when the pointer leaves the region.                                                                                        | Empty                |

While testing in-game, administrators can run `/arcmenu preview <menu-id> backend` to see the exact outlines of all backend regions on screen and check that they line up with the frontend buttons.

## Click types (`actions`)

`actions` can be written directly as a single action or action list (which triggers on any click), or broken down by click type:

| Click key        | Trigger                                                    |
| ---------------- | ---------------------------------------------------------- |
| `all` (or `any`) | Triggers on any click                                      |
| `left`           | Normal left-click                                          |
| `right`          | Normal right-click                                         |
| `middle`         | Middle-click (triggered via Minecraft's pick-block action) |
| `shift`          | Any click while holding sneak (Shift)                      |
| `shift-left`     | Shift + left-click                                         |
| `shift-right`    | Shift + right-click                                        |
| `shift-middle`   | Shift + middle-click                                       |

You can place shared feedback—like a button click sound—under `all` and assign specific tasks to individual click keys. When a single click matches multiple keys (for example, `Shift+right-click` matches `all`, `shift`, and `shift-right`), they run in the order they are written in the YAML file:

```yaml
backend:
  item-slot:
    x: 0
    y: 0
    width: 36
    height: 36
    actions:
      all: 'sound: UI_BUTTON_CLICK-1-1'
      left: 'open: item-details'
      right: 'cmd: shop buy 1'
      shift-right: 'cmd: shop buy 64'
```

## Hover and leave events (`on-hover` / `on-leave`)

When a player's gaze (Touch mode) or cursor (Mouse / Vision mode) enters or leaves a region, `on-hover` and `on-leave` let you build responsive hover feedback—such as playing a subtle sound or running a button scale-and-highlight animation:

```yaml
backend:
  card-area:
    x: 0
    y: -20
    width: 80
    height: 24
    on-hover:
      - 'sound: UI_BUTTON_CLICK-0.4-1.8'
      - 'animation: card-hover-in'
    on-leave:
      - 'stop-animation: card-hover-in'
      - 'animation: card-hover-out'
    actions:
      right: 'tell: &aSelected this card.'
```

How hover events behave:

* **Single trigger**: `on-hover` runs once when the pointer enters the region rather than repeating every tick while the pointer moves inside it; `on-leave` runs once when the pointer exits.
* **Clean transitions**: When the pointer slides directly from one button to an adjacent button, the old region's `on-leave` runs first, followed by the new region's `on-hover`.
* **Condition-aware**: If the region has a top-level `condition`, `on-hover` and `on-leave` only trigger for players who meet that condition. You can also write [conditional action groups](/en/menu-configuration/menus/conditions.md) directly inside `on-hover`.

To learn how to set up element animations like `card-hover-in`, see [Animation timelines and tracks](/en/feature-configuration/animations.md).

## Region conditions and deny feedback

Combining `condition` and `deny` on a button makes it easy to run normal actions when requirements are met and show a message when they are not:

```yaml
backend:
  vip-area:
    x: 60
    y: 0
    width: 70
    height: 22
    tooltip:
      - '&6VIP Pack'
      - '&7Click to claim your daily reward'
    condition: 'perm myserver.vip'
    deny:
      - 'sound: ENTITY_VILLAGER_NO-1-1'
      - 'tell: &cYou need VIP membership to claim this pack.'
    actions:
      right:
        - 'sound: ENTITY_PLAYER_LEVELUP-1-1'
        - 'console: give %player_name% diamond 5'
```

Even when a player does not meet the `condition`, hovering over the button still displays the `tooltip` so they can see what the button does. For custom tooltip styling, borders, and background images, see [Tooltips](/en/feature-configuration/tooltips.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.myarc.icu/en/menu-configuration/menus/backend.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.