Zum Inhalt

Custom Event Trigger — Cross-Action-Kommunikation

Action A feuert ein Custom Event → Action B (oder C, D, E) reagiert darauf. Modulares Pattern für Subroutinen ohne C#.

Sub-Action: Core → Triggers → Custom Event Trigger Trigger: Custom → Custom Doku: https://docs.streamer.bot/api/sub-actions/core/triggers/custom-event-trigger

Sender: Custom Event Trigger Sub-Action

Pfad: Core → Triggers → Custom Event Trigger

Feld Bedeutung
Event Name Frei wählbarer Identifier (z.B. newClip, subOfTheDay, gameDeath)
Use Args Toggle. Wenn aktiv → alle Variablen der Sender-Action werden an Empfänger übergeben

Empfänger: Custom Trigger

In der Empfänger-Action:

  1. Triggers-Tab → + Add Trigger → Custom → Custom
  2. Event Name eingeben: gleicher String wie beim Sender (case-sensitive)
  3. Event Name leer lassen = Catch-All (reagiert auf JEDES Custom Event)

Beispiel: Modulare Clip-Pipeline

[Cmd] !clip feuert newClip Event. Mehrere Listener-Actions reagieren parallel.

Sender: [Cmd] !clip erweitert

[Cmd] !clip
├── 1. Create Clip
├── 2. If/Else: %createClipSuccess% Equals false → Fehler + Break
├── 3. Global (Set): lastClipUrl = %createClipUrl%
├── 4. Send Message: "@%user% hat geclippt: %createClipUrl%"
└── 5. Custom Event Trigger:
       Event Name: newClip
       Use Args: ✅       ← gibt %createClipUrl%, %user%, etc. weiter

Empfänger A: [Sys] Clip Discord-Notify

Trigger: Custom → Custom (Event Name: newClip)

Sub-Actions:
└── Discord Basic Webhook:
     Content: 🎬 **@%user%** hat geclippt: %createClipUrl%

Empfänger B: [Sys] Clip History

Trigger: Custom → Custom (Event Name: newClip)

Sub-Actions:
└── Write To File:
     File: D:\clips-history.log
     Mode: Append
     Content: [%timestamp%] %user% → %createClipUrl%

Empfänger C: [Sys] Clip OBS Visual

Trigger: Custom → Custom (Event Name: newClip)

Sub-Actions:
├── 1. Set GDI Text: ClipNotifySource = "📸 @%user% just clipped"
├── 2. Set Source Visibility: ClipNotifySource = Visible
├── 3. Delay 5000 ms
└── 4. Set Source Visibility: ClipNotifySource = Hidden

Bei jedem !clip laufen ALLE drei Listener parallel.

Vorteile dieses Patterns

  • Modularität: !clip muss nicht wissen WAS passiert. Listener werden hinzugefügt/entfernt ohne !clip zu ändern
  • Multi-Plattform: Du kannst sowohl !clip als auch Reward Clip und Stream Online → autoClip feuern lassen — alle nutzen newClip als gemeinsame Pipeline
  • Test-friendly: Listener separat testen indem du Custom Event Trigger als Standalone-Action mit Test Trigger feuerst

Beispiel: Death-Counter mit Custom Event

Game schreibt Tod-Event in Log-File → File Watcher liest's → fired Custom Event gameDeath → mehrere Listener reagieren.

[FileWatcher] Game Log Death
Trigger: Core → File Folder Watcher → Changed
├── 1. Read Last Line From File
├── 2. If/Else: %lastLine% Contains "PLAYER_DIED"
│   └── Custom Event Trigger: Event Name = "gameDeath", Use Args = ✅
└── Break

[Sys] Death Counter
Trigger: Custom → Custom (gameDeath)
├── Global (Set) Increment: deathCount (Persisted)
└── Send Message: "💀 Death #%deathCount%"

[Sys] Death OBS Effect
Trigger: Custom → Custom (gameDeath)
├── Set Source Visibility: DeathOverlay = Visible
├── Play Sound: wilhelm-scream.mp3
├── Delay 2000 ms
└── Set Source Visibility: DeathOverlay = Hidden

[Sys] Death Discord
Trigger: Custom → Custom (gameDeath)
└── Discord Basic Webhook: "💀 Streamer hat das Game verkackt"

Catch-All Listener

Wenn ein Listener auf JEDES Custom Event reagieren soll (z.B. Logging):

[Sys] Event Logger
Trigger: Custom → Custom (Event Name: leer)
└── Log: "Custom event fired: %actionName% with args %eventName%"

Praktisch für Debugging.

Use Args Detailed

Mit Use Args = true:

  • Mitgegeben: alle lokalen Argumente der Sender-Action
  • Listener kann %user%, %createClipUrl% etc. direkt nutzen

Mit Use Args = false:

  • Listener kennt nur die Auto-Variablen seines eigenen Triggers
  • Sender-Daten gehen verloren

Empfehlung: Use Args = true, except wenn Listener bewusst clean starten soll.

Variante: Event-Pipeline mit Run Action

Wenn du sequentielle Reihenfolge willst statt parallel — siehe run-action.md. Run Action ruft eine SPEZIFISCHE Action mit Wait/No-Wait auf.

Häufige Fallen

  • Event Name Tippfehler — newclip ≠ newClip. Case-sensitive
  • Endlos-Loop — Action A → triggert Event → Action B reagiert + triggert das gleiche Event → Action A reagiert → Loop. Counter oder anderes Event-Name verwenden
  • Parallele Listener-Reihenfolge — nicht garantiert. Wenn Listener A vor B laufen MUSS → Run Action statt Custom Event
  • Args nicht erlaubt — manche Sub-Actions ignorieren übergebene Args. Im Zweifel mit Log testen

Quellen