Menus and Contexts

How the starting menu is selected

Config.Contexts is ordered. The first matching context with a usable menu wins. If that menu has no visible slots, the resolver can fall through to the next context. Keep a useful fallback such as the on-foot menu.

The public configuration has contexts for a mounted player, a player in a vehicle and a fallback player context. A horse menu does not populate itself with functions from an arbitrary stable resource; add the actions your server actually implements.

Add one independent test menu

Append this after the existing Config.Menus definition in shared/config.lua. It adds a demonstration menu without replacing other menus:

Config.Menus.docs_demo = {
    title = "Documentation test",
    slots = {
        {
            id = "print_test",
            icon = "clothing_generic_hat",
            label = "Print a test message",
            action = {
                type = "callback",
                value = function()
                    print("Radial documentation test")
                end,
            },
        },
    },
}

Restart the resource in a test session, run /radial docs_demo and select the action. Check F8 for the message. This deliberately performs no purchase or inventory action.

Slot fields

A submenu takes precedence over an ordinary action on the same entry. Menu-level slotsBuilder is available in 1.1.0 to build the whole menu's slots dynamically.

Keep predicates and builders quick and non-blocking: they are evaluated when building/refreshing the wheel. Cache server-derived information outside those callbacks. Hiding an action in the wheel is a UI decision, not a server permission check.

Test dynamic visibility

Check empty results, a missing integration resource and the player changing context. A menu disappearing because all its entries are hidden can be expected behavior. Use Actions and API for changes registered by another resource.