Skip to content

FOS Show Control — Standard

Version 1.0.0 · requires FOS Essentials Core 1.1.0 or later

A lighting, FX and cue console for your world. Requires FOS Essentials Core 1.1.0.

You bring the lights, the animations and the effects. This pack holds the show: which look is on, at what level, and how long it takes to get there — the same for everyone in the room, latecomers included.


Console ──► Show Director ──► Show Light → your Light
(buttons, (the show, and Show Material → your neon
faders) the only thing Show Particles → your smoke, your confetti
on the network) Show Toggle → your effects
Show Animator → your animations
Show Relay → ProTV, AudioLink, your scripts

Nothing on the right ever talks to anything on the left. Add a light without touching the console; rebuild the console without touching a single light.


Component Role
FOSShowDirector Holds the show. One per world. Alone on its GameObject.
FOSShowLight Drives one Light: an intensity and a colour per cue.
FOSShowToggle Switches a group of objects on or off per cue. Your FX go here.
FOSShowAnimator Plays one of your animations per cue, in phase for everyone.
FOSShowParticles Emits or fires one shot per cue. Smoke, confetti, sparks.
FOSShowMaterial Recolours an emissive surface per cue. Neon, LED, screens.
FOSShowRelay Sends a named event to any Udon behaviour on a cue.
FOSShowButton A console key: call a cue, black out, replay. Labels and lights itself.
FOSShowSlider A console fader: master level, or fade time.
FOSShowReadout Writes the show’s state into TextMeshPro labels.

Menu: Add Component > FOS Essentials > Show Control > ...


  1. Drop FOS Show Console into your scene, from the pack’s Prefabs folder or from FOS Essentials > Show Control. It brings the director with it: sixteen keys, a master fader, a fade fader, blackout and replay, already wired.
  2. On each of your lights, add a Show Light and drag the director into it. The director sits inside the console prefab, under Show Director.
  3. On an empty object holding your effects, add a Show Toggle and drag the director in.
  4. Light your scene by hand until cue 0 looks right. On the director, open the cue sheet, name the line, and press Store.
  5. Change the lighting, store it into cue 1. Repeat for as many looks as you need.
  6. Press Label the console keys on the director. A key carries its cue’s number and name from the cue sheet, so you type a name once and not twice.

That is the whole setup. Everything past this point is your venue, not the pack.

One director per world. The console prefab contains one; dropping the prefab twice gives you two shows that ignore each other. To drive the same show from a second surface, copy the console and point its keys at the first director.

Building your own console instead — a modelled desk, a wall panel, a handheld remote — is a matter of putting FOSShowButton and FOSShowSlider on your own objects and pointing them at the director. The manual walks through it, including the physical-desk case: a key answers Interact() as well as a UI Button, so the same component works on a modelled key with a collider.

Recall puts the scene back the way a stored cue had it, so you can go on editing a look you already recorded.

Every field on a Show Readout is optional, so put one wherever the console displays something: one in the header showing the cue number and name, another under the faders showing their figures. An operator who did not press the key still needs to know where the show is.


Nobody types sixteen intensities by hand, and nobody gets a good look that way. So the pack works like a real lighting desk: you build the look in the scene, then record it.

One consequence to know about: a cue is a number, not a content. The director only ever sends “go to cue 4, in 2 seconds” over the network, and each node holds its own table of values. That is why a hundred lights cost exactly the same bandwidth as one, and why a node added later stays dark on the cues it never knew — press Store again, or use the resize button the inspector offers you.


A Show Animator plays one of your animator states per cue. It knows nothing about what it plays — you write the state or trigger name, your controller does the rest.

Each client plays that animation on its own machine, so a looping one would drift: two players start it a moment apart, and somebody arriving later restarts it from zero. Tick align to the cue and fill in loop seconds, and the animation resumes where it should be by now instead of restarting — computed from the server clock the director shares, without a single byte on the wire.

A cue with an empty line does one of two things, and you choose which. Carry on lets the running animation continue — right for a set piece that spans several looks. Freeze stops it where it stands, until a later cue names a state again — right for a moving head that has no business sweeping any more. Freezing holds the pose rather than snapping back to the start.

If you would rather control what “stopped” looks like, add an Idle state to your own controller and name it on those cues. That works whichever option you picked.


You want Node Why that one
Neon or LED that changes colour Show Material costs almost nothing to draw, and carries a whole look on its own
Smoke, fog, snow Show Particles, continuous stops emitting and lets what is airborne drift away
Confetti, pyro, a spark hit Show Particles, burst one shot as the cue comes up, fired again by Replay
A laser rig, a prop, a banner Show Toggle on or off, nothing in between
Anything that moves Show Animator your animation, your controller

A Show Material writes through a property block, so it never touches your material asset and ten objects sharing one material can each show a different colour.

The dark-neon trap: on the Standard shader, writing _EmissionColor does nothing while the material’s Emission checkbox is off. That checkbox compiles a shader keyword, and no code can switch it back on. Tick it once — a black emission colour is fine — and the pack takes it from there.


What crosses the network, and what does not

Section titled “What crosses the network, and what does not”
Synced the cue number, the trigger count, the master, the blackout, the fade time, and the server time the cue started — about a dozen bytes, on the director alone
Not synced every node. A hundred lights cost exactly what one costs
Rebuilt on join everything. A latecomer reads the director’s state and lands mid-show, mid-fade-free, mid-animation

Anybody may drive the console: pressing a key takes ownership of the director. Restricting that to a crew is what FOS Access and FOS Show Control Pro are for.

Sending is throttled: a fader dragged across its travel produces one network update every fifth of a second, not fifty. What you see locally is never delayed — only the wire is spared.


FOSShowRelay sends an event name. That is deliberately all it does: a hard reference to ProTV would stop this pack from compiling for everyone who does not own it.

  • Point a relay at your ProTV player, write the event you want on the cue’s row, and tick relay from the operator only — otherwise every client in the room fights for ownership of the video player.
  • The same relay drives AudioLink, USharpVideo, or a behaviour you wrote yourself.

Ready-made bridges — driving ProTV by track, making lights breathe with AudioLink’s frequency bands — are what FOS Show Control Pro adds.


  • One Update in the whole system, on the director, and it exits on the first line when nothing is fading. Your lights have none.
  • A Show Light switches its Light component off once it reaches zero. A realtime light at zero intensity still costs; a disabled one does not.
  • Realtime lights remain expensive on Quest whatever we do. Baked lighting plus a few realtime accents will always beat twenty realtime spots.

Two silent traps the inspector watches for you

Section titled “Two silent traps the inspector watches for you”
  • The director must be alone on its GameObject. VRChat applies one single sync mode per object, taken from the last behaviour on it: a node dropped next to the director would quietly break the whole show.
  • A toggle must never target its own object. A disabled object stops running its Udon behaviour, so it would never receive the cue meant to bring it back.

Sequencer and timeline, chases and strobes (computed from network time, so they cost nothing), colour presets, ready-made ProTV and AudioLink bridges, console access restricted by role through FOS Access, and a FOS Tablet System panel.