FOS Access

Version 1.0.1 · requires FOS Essentials Core 1.0.0 or later

Answers one question — does this player hold the key? — and lets anything in your world ask it. Requires FOS Essentials Core 1.0.0.

---

Components

Component	Role
FOSAccessList	Holds the sources and answers. One per list.
FOSAccessGate	Shows or hides objects depending on that answer. One per filtered spot.

Menu: Add Component > FOS Essentials > Access > ...

---

Setup

1. Create an empty GameObject and add FOS Essentials > Access > Access List.
2. Fill at least one source (see below).
3. Point whatever needs the answer at that component — a FOSAccessGate, a door, your own behaviour.

Several independent lists — VIP, staff, event crew — means several FOSAccessList components, each on its own object. A list is a thing, not a category inside one component.

---

The four sources

They are cumulative: any single one granting access is enough.

Source	Changes without republishing	Answers instantly
List in the inspector	no	yes
Remote list (URL)	yes	no — it is a download
VRChat product	yes	no — it arrives with the purchase callback
Instance master	—	yes

The common setup is the first two together: the two or three people you trust shipped with the world, plus a list you can edit afterwards without opening Unity again.

The remote list format

One display name per line. Empty lines are ignored, and so are lines starting with #, which is how you annotate the file:

# staff
Frankk Darko
# guests for the January event
Some Player

The # rule applies only to the remote list. In the inspector a name is a name — a display name is perfectly allowed to start with a hash.

Moving names between the two

The inspector has Import from a file and Export to a file, and both use the format above. So an inspector list can be exported and hosted as is, and a file already online can be pulled back into the prefab. One name per line means one column, which is why there is no CSV here — nothing would separate.

---

Loading, and why a “no” is not always a “no”

While a remote list is downloading, the list cannot honestly answer. FOSIsResolved() tells you whether the answer is final:

• a yes is always final — sources only ever add people, none can take back what another granted, so someone already in the inspector list is in for good;
• a no is final only once nothing is in flight.

An interface that refuses should tell the two apart. “You are not on the list” and “the list has not arrived yet” are not fixed the same way — and a player who is told neither simply concludes the button is broken.

---

Public API

Call	Answer
FOSIsAllowed()	Does the local player hold the key?
FOSIsResolved()	Is that answer final?
FOSState()	StateLoading, StateReady or StateFailed
FOSRegister(behaviour)	Be sent FOSApplyAccess whenever the answer changes

A behaviour that registers must expose a public, parameterless FOSApplyAccess().

---

The gate

FOSAccessGate sits on what it filters rather than listing it centrally: the rule lives where the object lives, you see it by selecting the object, and it follows the object if you move it.

It never touches its own GameObject. That is not a nicety — an Udon behaviour on a disabled object stops running, so it would never receive the answer meant to switch it back on. It would stay dark until the world restarts, with no error and no explanation. Left with no explicit targets, it drives its direct children instead: put the gate on an empty object and park underneath it whatever should be filtered.

---

What this is not

It tidies a world. It does not protect it.

The answer is computed on the player’s own client, so a modified client can answer whatever it likes, and a remote list served over a public URL is readable by anyone. Udon offers nothing better — there is no server-side check to appeal to.

Put nothing in a list but display names, and never let this decide anything you would mind a determined visitor reaching.

---

Credits

French Oasis Studio SAS — contact@frenchoasis.studio