Home / Lua scripts
Scripts · UNC coverage · script hubs
Solara Executor submits Lua into a Roblox Player session that is already running. This page covers how that pipeline behaves, what people actually mean by UNC coverage, why a script hub can work in one place and fail in the next, and how to read Lua you did not write.
The order is fixed, and most confusing symptoms come from getting it wrong. You launch the official Roblox Player and join a place, then start Solara Executor with administrator rights and attach it to that running process. Only then does the editor have somewhere to send Lua. What you submit executes inside the session already live in front of you — not queued for later, not written into the place, not stored anywhere on your behalf. Close Roblox or disconnect and whatever your Lua set up is gone with the session.
The runner also executes what you give it and makes no judgement about what the code does. There is no allowlist, no review step and no scanner between the editor and the session. A script that spams a remote until the server kicks you runs exactly as readily as one that prints a number. The review section below exists because that responsibility sits with you; the overview page covers the execution model in more depth.
UNC is a community naming convention. Third-party Roblox script environments each expose functions beyond standard Lua — for reading the client, touching the filesystem, hooking calls — and historically each named them differently. The convention exists so that a script written for one runner has a reasonable chance of working on another, because the names line up. It is a shared vocabulary, not a certification, and not something a runner passes or fails as a whole.
Coverage is therefore a per-function matter. An environment either exposes a given function, exposes something that carries the name but behaves partially, or does not expose it at all, and what matters is whether the functions your script calls are present. Compressing that into one number means deciding which function list counts and how generously to grade partial implementations, and both decisions move the result enormously. Advertised percentages are close to meaningless as a result, because a high figure tells you nothing about the one function you happen to need. This site publishes no percentage and no function list for this build, since any such figure would be marketing rather than a measurement you could act on.
What you can do is read failures accurately. An error such as attempt to call a nil value naming a specific function is precise: that name is not bound to anything here, so the script asked for a function, received nil, and tried to call it. That is a coverage gap, not a broken install. The tell is that everything else keeps working — a trivial statement still executes, and only the code path that touched the missing function dies. If nothing executes at all, the problem is a different one and the install guide is where to start.
A script hub is Lua with a menu on top. The loader is Lua, the modules are Lua, and the interface is Lua building Roblox GUI objects. It gets no special treatment from the runner, so every rule on this page applies to a hub as it applies to a snippet you typed yourself.
Load order is what people get wrong. Attach first and wait for the attach to confirm, run one trivial statement to prove the pipeline is live, and only then load the hub. Skip that middle step and a failure tells you nothing, because you cannot distinguish an attach that never completed from a loader whose first module errored.
Hubs that work in one game and fail in another are the norm, for two ordinary reasons. Hub code is written against a specific place: it walks object paths and fires remotes that exist there and nowhere else, so elsewhere those paths resolve to nothing and the script dies on a missing object. The second reason is coverage — a hub written for an environment that exposes a function yours does not will fail at the line that calls it.
Isolating a broken hub is mechanical. Load its modules or sections individually and watch for the first failure, since later errors are usually consequences of the first. Then read the error text: a missing object path points at the game, a nil function name points at coverage, a syntax error points at a truncated paste. Assuming the runner is at fault is wrong most of the time.
This habit takes less time than people expect. A script executing inside your session has the reach of that session: it sees what your client sees and acts as your client acts. Read a hub before you load it — none of the signs below is decisive on its own, but each is a reason to look once.
loadstring or HttpGet call pulling a URL you cannot inspect means the code you reviewed is not the code that will run, and whoever controls that URL can change it at any time.If a script fails these checks, read it in full before you load it. The install guide covers the first test statement.
Start with a single trivial statement every time — one print, nothing else — before anything substantial. It costs a second and makes the next failure unambiguous, because you already know the attach completed and the editor is reaching the session.
Then change one thing at a time, and keep a known-good minimal snippet as a control. Run it whenever you are unsure whether the runner or the script is at fault: if it still executes, the fault is in what you just changed; if it stops too, session state is the suspect and troubleshooting covers the usual causes. If you have not reached a working attach yet, start with the install guide.
| Error you see | What it usually means | Where to look |
|---|---|---|
| Nil value error naming a function | That function is not exposed here — a coverage gap, not a broken install | The UNC section above |
| Nothing executes at all | The attach never completed | Install guide |
| Works in one game only | Object paths and remotes specific to that place | The script hub section above |
| Everything broke after a Roblox update | The client changed underneath the tool | Changelog |
| Crash on teleport | A stale session that does not carry to the new server | Troubleshooting |