Zum Inhalt

Run Action — Direkte Subroutinen

Action ruft eine andere Action direkt auf. Wie eine Function. Variablen werden geteilt.

Sub-Action: Core → Actions → Run Action Doku: https://docs.streamer.bot/api/sub-actions/core/actions/run-action

Felder

Feld Bedeutung
Action Welche Action ausgeführt werden soll
Run Action Immediately Toggle. ✅ = inline, wartet bis Action fertig. ❌ = async in eigener Queue

Run Immediately vs Async

Immediately (Synchron)

[Cmd] !x
├── 1. Send Message: "Start"
├── 2. Run Action: SubRoutine (Immediately ✅)   ← wartet bis fertig
└── 3. Send Message: "End"

Reihenfolge: Start → SubRoutine läuft komplett → End.

Async

[Cmd] !x
├── 1. Send Message: "Start"
├── 2. Run Action: SubRoutine (Immediately ❌)   ← läuft im Hintergrund
└── 3. Send Message: "End"

Reihenfolge: Start → End. SubRoutine läuft parallel im Hintergrund.

Variable-Sharing

Wenn Run Immediately = true: - Variablen die der Sub-Action setzt sind nach Run Action im Caller verfügbar - Caller's Variablen sind in der Sub-Action verfügbar

Beispiel:

[Sys] CalculateScore
└── Set Argument: finalScore = $mul(%input%, 2)$

[Cmd] !score
├── 1. Set Argument: input = 42
├── 2. Run Action: CalculateScore (Immediately ✅)
└── 3. Send Message: "Score: %finalScore%"   ← gesetzt von CalculateScore

Output: "Score: 84".

Use-Case A: Wiederverwendbare Helper-Action

Mehrere Commands brauchen gleiche Validierungs-Logik (Target-User aus Input ziehen + fallback).

Helper: [Sys] Resolve Target

[Sys] Resolve Target
├── 1. Set Argument: targetLogin = $replace(%input0%, @, )$
├── 2. If/Else: %targetLogin% Is Null or Empty
│   └── Set Argument: targetLogin = %userName%
└── 3. Get User Info for Target (User Login = %targetLogin%)

Caller: jeder Command der Target braucht

[Cmd] !iq
├── 1. Run Action: Resolve Target (Immediately ✅)
│      Setzt %targetLogin%, %targetUser%, %addTargetResult%, ...
├── 2. (Rest der !iq Logic)

[Cmd] !rose
├── 1. Run Action: Resolve Target (Immediately ✅)
├── 2. (Rest der !rose Logic)

[Cmd] !followage
├── 1. Run Action: Resolve Target (Immediately ✅)
├── 2. (Rest)

DRY: Don't Repeat Yourself. Bei Logik-Änderung nur EINE Stelle anpassen.

Use-Case B: Conditional Action-Dispatch

[Cmd] !mode
├── 1. If/Else: %input0% Equals "stream"
│   ├── Run Action: SetupStreamMode (Immediately ✅)
│   └── Break
├── 2. If/Else: %input0% Equals "brb"
│   ├── Run Action: SetupBrbMode (Immediately ✅)
│   └── Break
└── 3. Run Action: SetupChillMode (Immediately ✅)

Routing-Pattern: ein Command, viele Sub-Actions je nach Input.

Use-Case C: Async Background-Task

Aufwendige Operation soll nicht den Caller blockieren.

[Cmd] !generate-stats
├── 1. Send Message: "📊 Stats werden generiert, dauert kurz..."
├── 2. Run Action: HeavyStatsGen (Immediately ❌)   ← async
└── 3. (Caller endet sofort, HeavyStatsGen läuft im Hintergrund)

HeavyStatsGen macht 30 Sekunden lang Berechnungen und postet am Ende selbst die Stats.

Custom Event vs Run Action

Wann Custom Event Run Action
Mehrere Listener ✅ Pattern dafür nein
1:1 Routing umständlich ✅
Variable-Sharing mit Use Args direkt
Sequential parallel sync möglich
Loose Coupling ✅ nein (Listener kennt Caller)

Faustregel: Run Action für 1:1-Calls, Custom Event für Pub/Sub.

Variante: Recursive Run Action

Eine Action kann sich SELBST aufrufen. Nutzbar für Polling/Retry-Patterns aber gefährlich.

[Sys] Wait For Condition
├── 1. Fetch URL: API-Status → %status%
├── 2. If/Else: %status% Equals "ready"
│   ├── Custom Event Trigger: "apiReady"
│   └── Break
├── 3. Delay 5000 ms
└── 4. Run Action: Wait For Condition (Immediately ❌)   ← rekursiv

Vorsicht: ohne Break-Condition Endlos-Loop. Plus: Streamer.bot kann bei tief geschachtelten Recursions abkacken.

Variante: Run Action Group

Core → Actions → Set Action Group State aktiviert/deaktiviert eine ganze Action-Gruppe. Nicht "Run all" — aber wenn du Stream-Modus-Wechsel hast, kannst du Gruppen disablen/enablen:

[Cmd] !stream-mode
├── Set Action Group State: "Stream Actions" = Enabled
└── Set Action Group State: "BRB Actions" = Disabled

So switchst du zwischen "Stream-aktive Actions" und "BRB-Modus-Actions".

Häufige Fallen

  • Action nicht selektiert — Sub-Action zeigt leeres Ziel → silently fails
  • Run Immediately = false misverstanden — wenn du Variablen vom Sub-Action brauchst MUSS Immediately ✅ sein
  • Recursive Endlos-Loop — immer Exit-Bedingung
  • Caller pausiert ewig — wenn Sub-Action 60s+ braucht, blockiert Caller. Async oder Queue nutzen
  • Sub-Action Caller braucht Trigger — eine Action ohne Trigger kann trotzdem via Run Action aufgerufen werden. Ist OK

Quellen