🚫 Restricting Menu Access

Sometimes you want to lock a menu down based on permissions, conditions, or world. NxMenu has three layers of access control.

Layer 1: Open Requirements

The Inspector has an OPEN REQUIREMENT card with four modes:

NONE

Any player who can run the trigger command can open the menu.

STANDARD

Custom condition. Choose a placeholder, operator, and value.

Example: %player_level% >= 10 &cYou need level 10!

ONLINE CHECK

Verify a target player is currently online. The default target is %arg1%, perfect for profile menus.

Example: Target = %arg1%, Deny = &cThat player is offline!

PERMISSION

Check a permission node.

Example: Perm = nxmenu.shop.vip, Deny = &cVIP rank required!

Layer 2: World Restrictions

The Inspector has DENY WORLDS and DENY MSG fields:

• DENY WORLDS: Comma-separated list of world names where the menu is blocked
• DENY MSG: Message shown if a player tries to open it in a blocked world

Example: Set DENY WORLDS to pvp_arena, dungeon_1 to prevent menu access in combat zones.

Layer 3: Per-Slot Conditions

Even if a player can open the menu, individual slots can have their own gates via [require] action blocks or State System overrides. See the State System section for details.

Best Practices

• Use Open Requirements for high-level access (rank checks, level gates).
• Use Deny Worlds for context restrictions (no shop in PvP areas).
• Use per-slot [require] for fine-grained item-level gating (e.g. need money for THIS purchase).
• Use States when you want to show the locked state visually instead of blocking access entirely.