Streamer.bot Decks & Actions Setup

Part 1 How it fits together

Everything runs through one action: Cam360 Control. It holds the v4.5 C# script, the OBS WebSocket plumbing, the chat command triggers, and the blocking camera queue. You never copy that script anywhere else.

Deck buttons don't talk to the engine directly. Each button fires a tiny wrapper action whose only job is to hand the engine a note — an argument named camAction — and ring its doorbell. The engine reads the note and performs the move.

Chat commands (!cam, !spin, !zoom, !barrelroll, !corkscrew) skip the wrappers and hit the engine directly — both paths merge in the same queue, so a deck press landing mid-!spin simply waits its turn.

Part 2 Before you start

• Cam360 Control action exists with the v4.5 script compiled (no red errors in the code editor)
• The action's Queue is set to camera — a blocking, non-concurrent queue (create it under Settings → Queues if it's missing)
• Chat commands already work: !cam left pans, !spin spins
• OBS is connected in Streamer.bot (Servers/Clients → OBS Studio shows green)

If any of these fail, fix them on the main guide first — the deck layer sits entirely on top of a working engine.

Part 3 Build your first wrapper

We'll build Cam Spin. Every other wrapper is this exact recipe with a different name and a different camAction value.

1. Create the action. In Streamer.bot's Actions tab, right-click → Add Action. Name it Cam Spin. Optional but tidy: put all wrappers in a group called Cam Deck. Leave the wrapper's queue blank — the queueing happens on the core.
2. Add the note. Right-click its Sub-Actions pane → Core → Arguments → Set Argument.
   Variable Name: camAction  ·  Value: spin
3. Ring the doorbell. Right-click Sub-Actions again → Core → Actions → Run Action → select Cam360 Control.
   Leave "Run Immediately" UNCHECKED. This is the whole trick — unchecked means the engine runs on its own camera queue, so button mashing queues moves politely instead of fighting over the yaw. Checked would run it inline and bypass the queue.
4. Test it. Right-click the wrapper → Test Trigger. The camera should do a full spin. If it does, you've built your last hard one — the rest take about five seconds each.

Part 4 The full wrapper set

Make one wrapper per move you want on the deck. Same recipe every time; only the name and the camAction value change. Two-word values go in as a single string — e.g. Value: tilt 45, roll 15, or planet out.

Deck wrappers get the trusted FOV range (30–150). Chat's !zoom is clamped tighter (60–120) inside the script — so your deck can punch in further than viewers can.

While tiny planet is active, the Zoom In / Zoom Out wrappers automatically resize the planet instead of changing FOV — the same reroute chat's !zoom gets. Any framing wrapper (front, left, a heading, etc.) snaps back out of planet mode; spin and barrelroll keep it on.

Part 5 Put them on the deck

1. In Streamer.bot, open the Decks tab and create a deck (e.g. 360 Cam). Set rows/columns to fit your hardware or use it on-screen from the Streamer.bot mobile/web deck.
2. Add a button → set its action to a wrapper (Cam Left, Cam Spin, …). One button per wrapper. Label and color it however you like.
3. Using the official Elgato Stream Deck instead? Install the Streamer.bot Stream Deck plugin, then drag its "Do Action" tile onto a key and pick the wrapper from the dropdown. Same wrappers, same queue, same behavior.

A layout that's worked well — directions across the top, motion moves in the middle, zoom on the bottom row:

Part 6 Test checklist

• Press Spin — full smooth 360, ends where it started
• Mash Left / Right / Front quickly — moves queue up and play one after another, no snapping
• Press Zoom In twice, then Front — pan happens but zoom holds
• Press Zoom Reset — FOV glides back to 115
• Type !spin in chat, then immediately press Barrel Roll — spin finishes, then the roll fires
• Right-click a raid/sub wrapper → Test Trigger — no need to wait for a real event

Part 7 Troubleshooting