> For the complete documentation index, see [llms.txt](https://project-07.gitbook.io/project_07-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://project-07.gitbook.io/project_07-docs/scripts/project07-radialmenu-v2/troubleshooting.md).

# Troubleshooting

Troubleshooting: "some radial items still show a plain/default UI" If most scripts route into Project07's menu fine, but one specific script's button (e.g. a minigame's "Leave"/"Surrender" button) sti

### 1. Is it actually a *radial* item at all?

A lot of "floating button in the corner of the screen" UI elements are NOT ox\_lib's radial menu — they're a completely separate NUI the script drew itself (e.g. ox\_lib's **TextUI**, a custom minigame HUD, a simple `SendNUIMessage` button). Nothing about our bridge — or ox\_lib's own radial system — is involved in those at all, so there's nothing to "route" here.

**How to tell:** ox\_lib's radial (and Project07's) is a *segmented wheel* you open with a keybind and pick one of several options from. A single floating button with one icon and one action (like a paintball "Leave" button) is almost always its own separate UI, unrelated to any radial menu. If that's what you're seeing, this isn't a bridge issue — you'd need to look at how that specific script draws that specific button.

### 2. Confirm the bridge is actually installed and being hit

`bridge/ox_lib_radial_override.lua` now prints a yellow debug line every time `lib.registerRadial` or `lib.addRadialItem` is called, including which resource called it:

ex:

```
[ox_lib radial bridge] addRadialItem(...) called by resource "pug_paintball"
```

* **Nothing prints when the script in question runs** → its calls aren't reaching this file at all. Skip to step 3.
* **It prints, but Project07's UI still doesn't show the item** → that's a mapping/data issue (e.g. the item's `onSelect` type isn't one this bridge handles) — open an issue with the exact `lib.addRadialItem(...)` call that script is using.

### 3. Look for MORE THAN ONE copy of ox\_lib on the server

Some resources bundle (vendor) their **own private copy** of ox\_lib's files instead of depending on the shared `ox_lib` resource via `shared_script '@ox_lib/init.lua'`. If that's the case, overwriting the shared `ox_lib` resource's radial file does nothing for that script — it's reading its own separate copy.

Run this from your server's `resources` folder to find every copy of ox\_lib's radial code:

```bash
grep -rl "function lib.registerRadial" . 2>/dev/null
```

If that returns more than one file path, you have more than one copy — replace **every** one of them with `bridge/ox_lib_radial_override.lua` (adjusting nothing except leaving `TARGET_RESOURCE` as-is), then restart each of those resources.