Zum Inhalt

Write To File — Audit-Logs und Persistente Daten

Speichert Action-Daten in lokale Files. Klassisch: Mod-Audit-Log, Stream-Stats-CSV, Backup von Globals.

Sub-Action: Core → File I/O → Write To File Doku: https://docs.streamer.bot/api/sub-actions/core/file-io/write-to-file

Felder

Feld Bedeutung
File to write to Pfad zur Ziel-Datei
Append to file Toggle. ✅ = anhängen, ❌ = überschreiben
Text to write Inhalt. Variablen-Interpolation aktiv

Use-Case A: Mod-Audit-Log

Bei jedem !ban / !timeout in eine Log-Datei schreiben für später-Review.

In der [Cmd] !ban Action (aus Mod-Welle) am Ende:

9. Write To File:
   File: D:\sb-logs\mod-audit.log
   Append: ✅
   Text: [%timestamp%] %userName% bannte %targetLogin% — %banReason%

Über die Zeit baut sich ein chronologisches Log auf. Mit Notepad öffenbar.

Use-Case B: Stream-Stats-CSV

Bei Stream-Ende eine Zeile mit Stats anhängen:

[Sys] Stream End Stats
Trigger: Twitch → Channel → Stream Offline
├── 1. Global (Get): totalSubs, totalFollows, totalBits
├── 2. Write To File:
│      File: D:\sb-logs\stream-stats.csv
│      Append: ✅
│      Text: %timestamp%,%streamDuration%,%totalSubs%,%totalFollows%,%totalBits%

CSV ist nach Stream in Excel/LibreOffice einlesbar für Trends.

Beim allerersten Stream Header anlegen:

[Sys] Init Stats CSV
Trigger: Custom → manuell ausgeführt
└── Write To File:
     File: D:\sb-logs\stream-stats.csv
     Append: ❌    (überschreibt)
     Text: timestamp,duration,subs,follows,bits

Use-Case C: Custom Quote-File

Statt SB-eingebautes Quote-System eine eigene quotes.txt:

[Cmd] !addmyquote
├── 1. If/Else: %rawInput% Is Null or Empty → Break
└── 2. Write To File:
       File: C:\sb-data\quotes.txt
       Append: ✅
       Text: %rawInput% — @%user% (%timestamp%)

Plus !quote-action liest Random Line aus der gleichen File:

[Cmd] !myquote
├── 1. Read Random Line From File: C:\sb-data\quotes.txt
└── 2. Send Message: "📝 %randomLine%"

Use-Case D: Globals-Backup

Wichtige Globals regelmäßig in JSON-File speichern für Disaster-Recovery:

[Sys] Backup Globals
Trigger: Timed Actions (alle 1h)
├── 1. Global (Get): deathCount → d
├── 2. Global (Get): subCount → s
├── 3. Global (Get): clipCount → c
└── 4. Write To File:
       File: D:\sb-backups\globals.json
       Append: ❌
       Text: {"deathCount": %d%, "subCount": %s%, "clipCount": %c%, "timestamp": "%timestamp%"}

Plus Restore-Action die das beim Stream-Start liest und Globals zurücksetzt (mit Read Lines From File + JSON-Parse).

Use-Case E: Twitch-Clip-Liste exportieren

Bei jedem !clip die URL in eine zentrale Master-Liste anhängen:

[Cmd] !clip (erweitert)
├── ... (bestehende Logic) ...
└── Write To File:
     File: D:\twitch-clips\all-clips.txt
     Append: ✅
     Text: [%timestamp%] %user%: %createClipUrl%

Am Stream-Ende hast du eine cleane History aller Clips.

Path-Handling Tipps

  • Absolute Windows-Pfade nutzen: D:\sb-data\file.txt
  • Forward-Slashes funktionieren oft auch: D:/sb-data/file.txt
  • Spaces im Pfad: lass Quotes weg, SB handhabt das
  • Variablen im Pfad: möglich, aber aufpassen mit Special Chars
  • D:\sb-logs\stream-%date%.log setzt z.B. Datum dynamisch
  • aber %date% muss auch valid Filename-Chars haben (kein :)

Pragmatisch: einfache Pfade, einfache Filenamen.

Variable: Dynamische Filenamen

Wenn pro Stream eine eigene Datei:

File: D:\stream-logs\session-$date(yyyyMMdd-HHmmss)$.log

Inline-Function $date()$ baut Filename mit aktuellem Timestamp. Vor jedem Stream-Start eine frische Datei.

Append vs Overwrite

  • Append (default Empfehlung): alle Daten bleiben erhalten, growing log
  • Overwrite: alte Daten weg, neue Datei. Use-Case: aktueller-Status-File

Beispiel für Status-File (wird ständig überschrieben):

[Event] HR Pulse → Status File
├── 1. Write To File:
│      File: D:\sb-status\heart-rate.txt
│      Append: ❌   (überschreibt)
│      Text: %heartRate% BPM (last update %timestamp%)

Anderer Service kann diese File pollen und immer den aktuellen Wert lesen.

Performance bei sehr häufigen Writes

Heart-Rate-Trigger feuert jede Sekunde. Write To File bei JEDEM Trigger = viel Disk-I/O. Empfehlung:

  • Bei häufigen Writes lieber Custom Webhook + externes Tool das aggregiert
  • Oder Write nur bei If/Else Schwellwert-Match
  • Oder File-Tail-Pattern (SB schreibt seltener, anderes Tool reads)

Häufige Fallen

  • Datei existiert nicht — Write To File legt sie automatisch an (samt Parent-Folder wenn nicht da)
  • Encoding-Issues — Default UTF-8. Emojis und Umlaute funktionieren meist
  • Bytes vs Zeichen — bei Logging mit Variable die Sonderzeichen enthält kann Encoding wichtig werden. Notepad öffnen, "Speichern als" → UTF-8 sicherstellen
  • Disk voll — bei Append-Logs ewig läuft die Datei voll. Periodisch rotieren (per separater Action die alte Files löscht)
  • File-Lock durch externes Programm — Excel sperrt offene CSV. Vor Write checken oder andere Datei nutzen

Read + Write Roundtrip

Pattern: read existing → modify → write back. Beispiel: User-Liste mit Counter.

[Cmd] !addvisit @user
├── 1. Read Lines From File: visits.txt
├── 2. (Parse, find user, increment count) — komplex ohne C#
└── 3. Write To File: visits.txt (Append false, full new content)

Pragmatisch ohne C# limitiert. Lieber Globals oder eingebautes Quote-System nutzen für komplexe Datenstrukturen.

Quellen