Every server already draws prompts from three or four places at once: ox_lib text UI in one
script, a target system in another, somebody's own DrawText3D in a third. They do
not know about each other, so the player sees three different styles in one minute.
The inserted line ends in then return end. That return value is the whole
design: true means we drew it and the original stops, false means we did not
and the original draws exactly as it always did. A prompt is rendered once — by us or
by them, never both.
ox_lib needs two lines: show and hide. One without the other leaves a prompt stuck on screen, which looks exactly like our bug. The server reads the file and says “HALF installed, 1 of 2 lines found” instead of letting you find out from a player.
When ox_lib updates and overwrites the file, the lines go with it. Every vendor has this problem. The difference is the console tells you on the next boot, and it tells never installed apart from was active before, missing now.
A row is keyed by the resource that registered it, automatically. Two scripts cannot overwrite each other, and when one stops, its rows go with it — without that script having to remember to clean up.
We can draw a target's option list in this panel. We cannot yet own the click — that happens inside the target's own UI. So those interceptions ship off, and the aiming reticle is never touched either way. The native mode, which owns selection too, is what turns them on.
No Wait(0) anywhere. The only thread that ever exists is a distance watcher,
alive solely while a coords-bound prompt is on screen, waking four times a second.
Not a feature count. These are the four things that decide whether it is still working six months from now.
Everything on this page runs the shipped UI. When the build lands on the store, the button above turns on and nothing else about it changes.