ASA Quick Note: Building Radial Menu Categories

ModsArkASAQuickNotesBlueprints

If I need a grouped radial menu in ARK: Survival Ascended instead of one flat action list, this is the pattern I would reuse from Shhhhh Hush Tames.

Core Idea

Use a persistent player buff as the UI owner and treat one top-level entry as the category anchor.

The practical shape is:

  • append one root MultiUseEntry such as Hush Preferences
  • mark it to persist the wheel on activation
  • on client activation, switch the wheel to that category
  • inside that category, build the real actions with stable derived UseIndex values

That keeps the root wheel clean and gives the feature room to scale without turning the first radial layer into noise.

The persistence part still matters. In this mod, the radial menu is not just a temporary action surface. It is the front end for player-specific preferences that survive sessions, so using a persistent buff as the owner keeps the UI and the saved state anchored to the same runtime object.

Flags That Matter

On the buff, the important setup is still the multiuse-related path:

  • Enable Multi Use
  • Blueprint Multi Use Entries
  • BPAdd Multi Use Entries
  • Allow Multi Use Entries from Self
  • persistent buff setup if the preferences need to survive sessions

If the buff is not the real owner of the entries, the category flow becomes harder to keep coherent. If the feature also stores long-lived preferences, the persistence setup is part of why this pattern works well.

Category Pattern

The reusable structure is:

  1. receive the incoming entries in BPGetMultiUseEntries
  2. copy them into a temporary array
  3. append a root entry such as Hush Preferences
  4. give that root a known UseIndex
  5. when that root is selected in BPClientDoMultiUse, call Set Multi Use Wheel Category
  6. rebuild the wheel entries for the selected category

That split matters because the category switch is client-side UI behavior, while the actual preference changes still need to be validated and applied through the authoritative path.

Stable Indexing Helps

One detail worth preserving was the index scheme.

Instead of hardcoding unrelated numbers everywhere, the category entries were derived from a base index pattern so related actions stayed grouped. A simple version is multiplying a category base and then offsetting within it, which makes BPTryMultiUse and Switch on Int much easier to maintain later.

That pays off as soon as the menu grows beyond two or three actions.

Why This Works Well

The main win is that the wheel stays understandable:

  • root wheel shows only the category entry
  • category view shows the real toggles
  • each action still has a stable index
  • the buff remains the single place that owns UI state

For a preference-driven mod like Shhhhh Hush Tames, that is much cleaner than trying to inject every toggle directly into the top-level wheel.

Practical Takeaway

If a radial feature in ASA is going to grow, I would not start with a flat list. I would start with:

  • persistent player buff as UI owner
  • one category entry at the root
  • category switch in BPClientDoMultiUse
  • stable derived indices for the real actions

That is a better foundation for future expansion than rebuilding a flat wheel later.