Verifying as a New Player
Your browser keeps a primed local copy of every project and pack you have opened. That is what makes the editor fast, and it is also the single most effective way to be the last person to find out that something you depend on has been deleted.
The failure looks like this. A pack you reference is taken down. You open your game, everything loads from your own copy, everything looks right. Every player who joins after that point gets grey placeholder boxes. Nothing tells you, because from where you are sitting nothing is wrong.
Verify in the editor toolbar is the answer to that. It fetches your published project and every pack it pins the way a stranger would — cold, from upstream, with none of your copies involved.
What it checks#
One row per thing a new player would have to pull:
- your project itself, at the exact commit it was published from;
- every pack your manifest pins, at its own pinned version.
Each row gets one of three verdicts, and the third one is not a softer version of the second.
| Verdict | What it means |
|---|---|
| Resolved | It was fetched cold and it is there. |
| Not published here / Taken down / Repository does not answer | It is genuinely missing for a new player. The row says which of the three, because "republish it", "it was withdrawn" and "the repository is gone" are different problems. |
| Could not check | The check was rate limited or timed out. This is not evidence that anything is missing. |
That last row is deliberate and it matters. If a throttled check reported "your dependency is gone", the warning would be wrong often enough that you would learn to ignore it — and this warning is the only thing standing between you and a silently broken table. So an inconclusive check says it is inconclusive, is counted separately, and never turns the run into a pass.
A run with nothing missing but something unchecked says so in those words. It is not a clean bill of health; try again in a few minutes.
Which caches were skipped#
The dialog lists this rather than asking you to take it on faith, because a verification that quietly consulted a cache would be worse than no verification at all.
There are three layers between a published file and a new player's screen:
| Layer | Who skips it |
|---|---|
| The verification service's own artifact cache | The service, by never consulting it — it issues its own requests rather than reading a stored copy. |
| The browser HTTP cache, and GitHub's edge | The service, structurally: it runs on a server, which has no browser cache, and it asks for a fresh copy explicitly. |
| Your own primed local copy | This button. Nothing on the server can reach into your browser's storage, so this is the one layer only the editor can skip — and it skips it by never reading it. |
The dialog prints the service's own description of each layer verbatim. If a layer ever appears that neither side skipped, it is called out in red and the run is marked incomplete rather than being presented as a whole check.
When to run it#
- After publishing, to confirm what you published is actually fetchable.
- Before telling people to join, especially for a table you have not opened in a while.
- Whenever a piece looks wrong to a player and fine to you. That asymmetry is the signature of this exact problem.
It is not automatic and it is not run on load. It makes real outbound requests to somebody else's repository, so it runs when you ask it to.
What it cannot do#
- It cannot stop a pack being deleted. Packs live in their authors' own repositories. Nobody here can prevent an author deleting theirs, and nothing tries to — this check exists because that is true, not instead of it.
- It only reaches published projects. A project you have never published has nothing a new player could pull, and the dialog says so rather than reporting a failure.
- Only the mod's owner can run it. It spends a request budget against GitHub.
- It is available in the Game Editor and the Asset Editor, the two editors that can hold a dependency. Room and Table packs declare none, so they have no pins to check.
If something is missing#
Read the row: it names the pack and its version, and it always says missing, never corrupt. That distinction is worth trusting — a missing file often surfaces elsewhere as a baffling parse error about a bad GLB header, which sends you looking for a broken file that does not exist.
Your options are the ordinary ones:
- pin a different version, if the author still publishes one;
- copy the pack in instead of referencing it, if you still have it locally — a copy cannot rot, at the cost of never receiving the author's fixes;
- replace the pieces with your own.