Ein eigenes HUD entwickeln

Dieser Leitfaden führt dich vom leeren Projekt zu deinem ersten eigenen HUD in sOU. Du installierst die Werkzeuge über NuGet, erstellst ein Projekt, passt die Darstellung an und prüfst dein fertiges Paket in der laufenden App. sOU liefert aufbereitete Spiel- und Paneldaten; dein HUD gestaltet daraus die Ausgabe.

Empfohlen ist Blazor WebAssembly mit C# und Razor-Komponenten. Der Weg über ein Webprojekt mit HTML, CSS und JavaScript ist ebenfalls voll unterstützt und bleibt dauerhaft unterstützt. Beide Wege erhalten dieselben öffentlichen Daten und Panelnachrichten. Du kannst auch ein Webframework wie React verwenden, solange dein Build ein lokal ausführbares Web-HUD erzeugt.

Vorlagen, Client und Paketwerkzeug beziehst du über NuGet. Die Befehle verwenden den gemeinsamen Paketstand 0.2.0-preview.4.

Dein Weg zum ersten eigenen HUD

1. Entwicklungsumgebung vorbereiten und Vorlagen und Werkzeug installieren.
2. Das empfohlene Blazor-WASM-Projekt oder ein Webprojekt erstellen. Die Vorlagen enthalten bereits die Daten- und Panelverbindung.
3. Eine Farbe oder Schriftgröße ändern, das Projekt paketieren und unter HUDs → Paket importieren in sOU installieren.
4. Die Ausgabe aus sOU öffnen und im HUD-Panel die Überschrift ändern und speichern. Ohne laufendes Spiel ist „Warte auf Spieldaten“ der erwartete Zustand; Paneländerungen müssen trotzdem ankommen.
5. Für Livewerte die GSI-Verbindung einrichten, CS2 starten und ein Spiel beobachten. Danach schrittweise eigene Datenanzeigen ergänzen.

Für den ersten Paneltest ist kein laufendes CS2-Spiel erforderlich. Zum Testen deines installierten HUDs brauchst du die sOU-App, ein Konto mit bestätigter E-Mail-Adresse und einen ausgewählten Workspace. Wie du dein Projekt danach erweiterst, erklärt der Abschnitt zu eigenen Ansichten und Komponenten. Bestehende LHM-/JT-HUDs kannst du nach der Importanleitung verwenden.

Welcher Entwicklungsweg passt zu dir?

Beide Wege verwenden hud.json für Name, Kennung und Version sowie wwwroot/panel.json für die Bedienfelder in sOU. Beginne mit der vorhandenen Vorlage und ändere zuerst nur Überschrift, Farben und Abstände. So bleibt die bereits funktionierende Datenverbindung erhalten.

Entwicklungsumgebung vorbereiten

Du benötigst einen Texteditor, PowerShell und das .NET-10-SDK. Prüfe mit dotnet --list-sdks, ob eine Version 10.x installiert ist. Beide Wege verwenden .NET für die Vorlageninstallation und das Paketwerkzeug; Blazor zusätzlich zum Bauen. Für Installation und Paketwiederherstellung muss nuget.org erreichbar sein. Bei einem eigenen Webframework benötigst du außerdem dessen Buildwerkzeuge, beispielsweise Node.js und npm.

Die vier Pakete haben unterschiedliche Aufgaben: SOU.Hud.Templates liefert die Projektvorlagen, SOU.Hud.Tool das Paketwerkzeug, SOU.Hud.Sdk den C#-Client und SOU.Live.Contracts dessen Datenmodelle. Die Paketlinks zeigen den jeweiligen Veröffentlichungsstand. Verwende Vorlagen, Werkzeug und C#-Abhängigkeiten aus demselben SDK-Stand.

Für die Webvorlage sind weder npm noch React, Vue oder TypeScript vorgeschrieben. Der Browser führt dein JavaScript aus; der vorhandene Microsoft-SignalR-Client wird lokal mitgeliefert. Blazor-HUDs werden als WebAssembly veröffentlicht und im Browser ausgeführt. Sie sind keine Erweiterungen, die eigene Assemblies im sOU-Host ausführen.

Vorlagen und Werkzeug einrichten

Lege ein neues Arbeitsverzeichnis für deine HUDs an und öffne dort PowerShell. Führe die folgenden Befehle darin aus. Sie installieren die Vorlagen und das Paketwerkzeug und legen den Ausgabeordner an. Bereits installierte HUDs in sOU werden dadurch nicht geändert.

Aus einer NuGet-Paketquelle installieren

Die passenden Paketseiten auf nuget.org: Vorlagen, Paketwerkzeug, C#-Client und Datenverträge.

New-Item -ItemType Directory -Path ./ausgabe
dotnet new install SOU.Hud.Templates@0.2.0-preview.4
dotnet tool install SOU.Hud.Tool --version 0.2.0-preview.4 --tool-path ./werkzeuge

Die Befehle verwenden deine eingerichteten NuGet-Paketquellen. Stelle sicher, dass nuget.org aktiviert und erreichbar ist. Das Werkzeug liegt danach unter ./werkzeuge/sou-hud. Führe die weiteren Befehle aus demselben Arbeitsverzeichnis aus; deine Projektordner liegen neben werkzeuge und ausgabe.

Installation prüfen

Mit dotnet new list sou-hud müssen die Vorlagen sou-hud-blazor und sou-hud-web erscheinen. Mit dotnet tool list --tool-path ./werkzeuge kontrollierst du das installierte Paketwerkzeug. Erstelle anschließend eines der folgenden Projekte.

Die Version 0.2.0-preview.4 bezeichnet die NuGet-Pakete. Sie ist unabhängig von der Protokoll-Hauptversion 2 und von der Version deines eigenen HUDs.

Blazor WebAssembly: der empfohlene Einstieg

Nach der Vorlageninstallation erzeugst du das C#-Projekt mit eigener Kennung. Vergib mit --hud-id eine dauerhafte eigene Paketkennung: mit einem Kleinbuchstaben beginnen, danach nur Kleinbuchstaben, Ziffern oder Bindestriche, höchstens 64 Zeichen. Unterschiedliche HUDs brauchen unterschiedliche Kennungen; neue Versionen desselben HUDs behalten ihre Kennung. Der Zielordner darf noch nicht existieren:

dotnet new sou-hud-blazor -n MeinBlazorHud --hud-id mein-blazor-hud -o ./mein-blazor-hud

Passe mein-blazor-hud/hud.json mit eigener ID, Name und Version an. Das folgende Beispiel verwendet die Version 1.0.0. Behalte runtime: "blazor-wasm", apiVersion: 2 und entryPoint: "index.html". Öffne für die erste sichtbare Änderung wwwroot/hud.css und ändere dort eine Textfarbe. In App.razor findest du das Markup und die bereits angeschlossene Live- und Panelanzeige. Lasse deren Verbindung zunächst bestehen. Anschließend veröffentlichst und paketierst du das HUD mit den folgenden Befehlen. Die Zielordner und die Ausgabedatei dürfen beim ersten Durchlauf noch nicht existieren.

dotnet publish ./mein-blazor-hud/MeinBlazorHud.csproj -c Release -o ./ausgabe/mein-blazor-paket
./werkzeuge/sou-hud pack ./ausgabe/mein-blazor-paket ./ausgabe/mein-blazor-hud-1.0.0.souhud
./werkzeuge/sou-hud validate ./ausgabe/mein-blazor-hud-1.0.0.souhud

Der Publishordner enthält bereits hud.json, LICENSE und den veröffentlichten wwwroot-Ordner. Das Manifest muss nicht mehr von Hand kopiert werden. Prüfe insbesondere, ob panel.json, Schriftdateien und Bilder mitveröffentlicht wurden. Liefere benötigte Lizenzdateien mit. Verwende bei einem weiteren Stand einen neuen beziehungsweise leeren Publishordner und eine neue Paketdatei.

Importiere jetzt ausgabe/mein-blazor-hud-1.0.0.souhud in sOU und öffne die Ausgabe. Ändere die Überschrift im Panel und speichere. Kommt die Änderung an, kannst du eigene Komponenten ergänzen. Weitere Prüfschritte stehen unter Prüfen, importieren und aktualisieren.

C#-Client und Lebensdauer

Die Vorlage enthält bereits die vollständige Komponente mit Live- und Panelverbindung. Ändere zuerst das Markup in App.razor oder die CSS-Datei und führe die obigen Buildbefehle aus. Der folgende Ausschnitt erläutert den Client; er ersetzt nicht die vollständige Komponente aus der Vorlage.

var hud = new HudClient(httpClient, new Uri(packageAddress));
hud.ConnectionChanged += (channel, status) => {
    // In Blazor Änderungen über InvokeAsync in die Oberfläche übernehmen.
};

await foreach (var snapshot in hud.WatchAsync(cancellationToken))
{
    if (snapshot.Game is { } game)
    {
        int? health = game.ObservedPlayer?.Health;
        string? teamId = snapshot.ManagedMatch?.Ct.TeamId;
    }
}

Benötigte Namespaces sind SOU.Hud.Sdk und SOU.Live.Contracts. WatchAsync und WatchPanelAsync sind getrennte asynchrone Streams: Starte beide parallel, wenn dein HUD beide benötigt. Ein endloser Live-Stream, den du zuerst vollständig abwartest, lässt keinen anschließenden Panel-Stream starten. Die Vorlage zeigt die parallele Ausführung mit Task.WhenAll.

Halte den übergebenen HttpClient für die Lebensdauer des HUDs bereit. Die Clientklasse verwendet die lokale Browsersitzung; eigene Zugangsdaten sind dafür nicht nötig. Bei DisposeAsync der Komponente den gemeinsamen Abbruchtoken auslösen, beide Aufgaben asynchron abwarten und die Tokenquelle freigeben. Ereignisbehandlung darf keine unbehandelten Fehler werfen. HudSdkJson.Default stellt die generierten JSON-Typinformationen für WASM und Trimming bereit.

Webprojekt: HTML, CSS und JavaScript

Dieser Weg ist voll unterstützt und bleibt dauerhaft unterstützt. Die NuGet-Vorlage liefert den offiziellen JavaScript-Client, Typdefinitionen und SignalR bereits lokal mit. Du kannst direkt mit der Vorlage starten oder ein eigenes Webframework verwenden. Dessen fertige Dateien müssen samt lokalen Abhängigkeiten im wwwroot-Ordner des HUD-Pakets liegen; ein Entwicklungsserver wird nicht mit ausgeliefert.

Vorlage und Paketidentität

dotnet new sou-hud-web -n MeinWebHud --hud-id mein-web-hud -o ./mein-web-hud

Der Zielordner mein-web-hud darf noch nicht existieren. -n bestimmt den Anzeigenamen. --hud-id ist erforderlich und bestimmt die eigene dauerhafte Paketkennung: mit einem Kleinbuchstaben beginnen, danach nur Kleinbuchstaben, Ziffern oder Bindestriche, höchstens 64 Zeichen. Unterschiedliche HUDs brauchen unterschiedliche Kennungen; eine neue Version desselben HUDs behält ihre Kennung.

Prüfe danach mein-web-hud/hud.json und ändere die version für das folgende Paketbeispiel auf 1.0.0. Behalte runtime: "web", apiVersion: 2 und entryPoint: "index.html". Der JavaScript-Client liegt bereits unter wwwroot/sdk. Den Paketbefehl findest du unter Prüfen, importieren und aktualisieren.

Daten abonnieren

Die Vorlage enthält bereits eine vollständige HTML-Seite und die folgende Verbindung. Für deinen ersten Versuch musst du sie nicht neu schreiben: Ändere in wwwroot/hud.css eine Farbe oder die Schriftgröße, erstelle das Paket wie unter Prüfen und importieren und öffne deine Ausgabe. Die folgenden Beispiele erklären anschließend, wie du eigene Datenanzeigen ergänzt.

Lade den mitgelieferten SignalR-Client vor deinem Modul. Die Dateien müssen im Paket liegen; absolute Dateipfade oder CDN-Adressen sind dafür nicht geeignet.

<script src="sdk/vendor/signalr.min.js"></script>
<script type="module" src="hud.js"></script>

Eine kleine wwwroot/hud.js kann so beginnen. Die Elemente score, caption und connection müssen in deiner HTML-Datei existieren.

import { HudClient } from './sdk/sou-hud.js';

const hud = new HudClient();
const lifetime = new AbortController();
const text = (id, value) => {
  document.getElementById(id).textContent = value;
};

hud.watch(snapshot => {
  const game = snapshot.game;
  text('score', game
    ? `${game.ct?.score ?? '–'} : ${game.t?.score ?? '–'}`
    : 'Warte auf Spieldaten');
}, {
  signal: lifetime.signal,
  status: (channel, status) => {
    if (channel === 'live') text('connection', status);
  },
  error: error => console.error('HUD-Verbindung:', error)
});

hud.watchPanel(message => {
  if (message.state) {
    text('caption', message.state.values.display?.caption || 'Mein HUD');
  }
  if (message.action?.name === 'cue') {
    // Nur auf diese neue Aktion reagieren; nicht als Einstellung speichern.
  }
}, { signal: lifetime.signal });

window.addEventListener('pagehide', () => lifetime.abort(), { once: true });

textContent setzt empfangene Texte als Text. Verwende für Teamnamen, Spielernamen und Paneltexte keine ungeprüfte HTML-Einfügung. Externe Inhalte sind Daten, kein vertrauenswürdiges Markup.

JavaScript-Clientvertrag

contracts.d.ts beschreibt die Daten für Editoren. Du kannst die vollständige Typreferenz durchsuchen oder die Vertragsdatei herunterladen; diese Datei ist kein vollständiges SDK-Paket. sou-hud.d.ts ergänzt die Clientmethoden. Der JavaScript-Client normalisiert neue Enum-Namen auf unknown, sofern der betreffende Vertrag einen solchen Wert besitzt. Du musst dafür kein TypeScript-Projekt einführen.

Deine erste eigene Anzeige ergänzen

Erweitere das funktionierende Projekt jeweils um eine Anzeige und prüfe sie im importierten Paket. So erkennst du, welche Änderung ein Problem verursacht.

1. Mapname: Lies im Live-Empfang snapshot.Game?.Map in C# beziehungsweise snapshot.game?.map in JavaScript. Binde den Wert an Razor-Markup beziehungsweise ein HTML-Element mit textContent. Fehlt er, zeige einen Wartezustand. Die Datenübersicht führt dich zu weiteren Anzeigen.
2. Überschrift aus dem Panel: Ändere das vorhandene Feld display.caption in wwwroot/panel.json und seine Darstellung im HUD. Lies den Wert in C# mit state.Text("display", "caption"), im Web mit message.state.values.display?.caption. Die Schrittfolge für Bedienfelder erklärt Definition, Empfang und Darstellung.
3. Eigene Ansichten und Medien: Ergänze erst danach Logos, Spielerbilder oder zusätzliche Ausgaben. Die Paketreferenz erklärt Dateien und Manifest; die Metadatenreferenz erklärt die Zuordnung zu deinen vorbereiteten Teams.

Erhöhe für jede geänderte Ausgabe die Version, baue und importiere das Paket erneut und öffne seine neue Ausgabe. Prüfe sowohl vorhandene als auch fehlende Werte. Die folgenden Regeln helfen dir, dabei keine falschen Spielinformationen anzuzeigen.

Zustände korrekt darstellen

Ein Snapshot ist ein vollständiger aktueller Datenstand. Für eine erste Anzeige genügt game; dort findest du etwa Map und Spielstand. Für Namen und Logos deiner vorbereiteten Teams verwendest du zusätzlich managedMatch. Suche ein konkretes Feld in der Typreferenz; die API-Anleitung erklärt seine Herkunft und Bedeutung.

• Vor dem ersten GSI-Paket: game ist null. Ein ausgewähltes managedMatch kann trotzdem bereits Teams, Serie und Startzeit liefern.
• Verbindung und Frische: connected bedeutet erreichbarer Transport. Ob neue CS2-Daten vorliegen, steht in snapshot.freshness.
• Fehlende Daten: null, leere Listen und unknown unterscheiden. Aus fehlenden HP keinen Tod, aus fehlendem Spielstand kein 0:0 und aus einer leeren Mapliste kein Veto erfinden.
• Seiten: Die fertige Team-ID aus managedMatch.ct beziehungsweise managedMatch.t verwenden. Bildschirmseite, Spielerreihenfolge und CT/T allein ergeben keine dauerhafte Teamidentität.
• Sitzungswechsel: Ändert sich sessionId, eigene sitzungsgebundene Animationen und Zwischenspeicher zurücksetzen. Ein einzelner Stream enthält vollständige Zustände, keine garantiert lückenlose Ereignisfolge.
• Panel: Zustand erneut anwenden können. Einmalige Aktionen nur beim Eintreffen behandeln; nach Reconnect kommen vergangene Aktionen nicht erneut.
• Medien: Fehlende Bilder mit einer passenden leeren Darstellung behandeln. Namen, Logos oder Fotos unbekannter Teams und Spieler nicht ersetzen, als wären sie echte Profildaten.

Prüfen, importieren und aktualisieren

Für das Webprojekt aus dieser Anleitung erzeugst du nach deinen Änderungen ein Paket mit den folgenden Befehlen. Die Ausgabedatei darf noch nicht existieren; verwende bei weiteren Paketständen eine neue Version in Manifest und Dateiname.

./werkzeuge/sou-hud pack ./mein-web-hud ./ausgabe/mein-web-hud-1.0.0.souhud
./werkzeuge/sou-hud validate ./ausgabe/mein-web-hud-1.0.0.souhud

pack erstellt und prüft das Archiv. validate prüft ein vorhandenes Archiv auf die Installationsanforderungen von sOU. Ohne Argumente oder mit falscher Syntax liefert das Werkzeug Exitcode 2, bei abgewiesenen Paketen Exitcode 1, bei erfolgreicher Prüfung Exitcode 0. Die Blazor-Paketierung ist im Blazor-Abschnitt beschrieben.

Importiere ein gültiges Paket unter HUDs → Paket importieren. Öffne seine angebotene Adresse oder seine OBS-/Overlay-Ausgabe. Ein direkter Start von index.html per file:// besitzt weder die Paketidentität noch den lokalen Transport. Details zum Benutzerablauf stehen unter HUDs installieren und HUDs ausgeben.

Prüfe vor einer Weitergabe mindestens den Start ohne Spiel, ein vorbereitetes Match vor GSI, fehlende Teamzuordnung, veraltete Daten, Seitenwechsel, Host-Neustart, Paneländerungen und Reconnect. Prüfe außerdem die tatsächliche Zielauflösung in OBS, Transparenz, lange Namen und fehlende Medien. Synthetische Daten gehören ausschließlich in einen getrennten Entwicklungsbetrieb, niemals in einen laufenden echten Cast.

Für jedes geänderte Paket eine neue Version erzeugen. Eine bereits installierte Kombination aus ID und Version ist unveränderlich. Laufende Ausgaben bleiben an ihrer geladenen Version; die stabile Adresse wählt beim nächsten Laden die vom Host angebotene Version. Die Versionsregeln und die Übernahme von Panelwerten erklären die Folgen für Updates.

Dein HUD Schritt für Schritt erweitern

1. Eigene Gestaltung: HTML beziehungsweise Razor und CSS ändern. Die vorhandenen IDs der Webvorlage erhalten, solange hud.js sie verwendet. Paketkennung und erste Version in hud.json festlegen.
2. Erste eigene Datenanzeige: Im vorhandenen Empfangscode ein Feld aus dem Snapshot lesen. Beispielsweise liefert snapshot.game?.map in JavaScript beziehungsweise snapshot?.Game?.Map in Razor den Mapnamen. Ohne Map einen leeren Text oder einen Wartezustand anzeigen.
3. Bedienfelder: wwwroot/panel.json anpassen und die empfangenen Werte im HUD anwenden. Ein Feld im Panel erzeugt noch keine Darstellung im HUD. Das vollständige Panelbeispiel erklärt Schema, Werte und Aktionen.
4. Bilder und weitere Ansichten: Eigene Assets im Paket ablegen; Medien aus sOU über media beziehungsweise Media auflösen. Zusätzliche Ausgaben als Subviews im Manifest anmelden.
5. Änderung ausprobieren: Version in hud.json erhöhen, etwa von 1.0.0 auf 1.0.1. Web erneut paketieren; Blazor erneut in einen neuen Publishordner veröffentlichen und diesen paketieren. Neue Namen für Publishordner und Ausgabedatei verwenden, damit keine alten Dateien in den nächsten Stand geraten. Danach importieren und die Ausgabe neu laden.

Die laufende Ausgabe wechselt nicht automatisch zur neuen Version. Kontrolliere bei einer scheinbar unveränderten Darstellung zuerst die installierte Version und lade die Ausgabe neu. Bewahre deinen Quellprojektordner auf: Die fertige .souhud-Datei ist für Installation und Weitergabe gedacht.

Für eine transparente Spielfläche müssen html, body und das Wurzelelement deiner Anwendung transparent bleiben. Erzwinge auf der Dokumentwurzel kein color-scheme: dark: Bei einem anderen Farbschema des einbettenden Rahmens kann der Browser trotzdem eine deckende Fläche zeichnen. Dunkle Anzeigeflächen kannst du direkt an den einzelnen HUD-Elementen festlegen. Prüfe das fertig installierte Paket über einem sichtbaren Hintergrund und anschließend in deiner CS2-/OBS-Ausgabe; eine transparente CSS-Farbangabe allein belegt das Ergebnis nicht.

Wenn der erste Versuch nicht funktioniert

Dein Projekt schrittweise erweitern

Beginne mit einer der oben beschriebenen NuGet-Vorlagen. Ergänze zuerst eine einzelne Anzeige, prüfe die Datenverbindung und baue danach weitere Komponenten ein. Dein Manifest erhält eine eigene dauerhafte Kennung, einen eigenen Namen und eine neue Version für jeden geänderten Paketstand.

Eigene Ansichten anbieten

Du kannst neben der Hauptausgabe zusätzliche Ansichten für unterschiedliche Sendesituationen erstellen, beispielsweise eine Matchvorschau, Kaderübersicht oder Ergebnisansicht. Welche Ansichten dein HUD anbietet und welche Daten sie benötigen, legst du selbst fest. Registriere jede zusätzliche Ansicht im Manifest. sOU stellt danach die passende Ausgabeadresse bereit; verwende diese Adresse in der jeweiligen OBS-Browserquelle.

Alle Ansichten derselben Paketversion erhalten dieselben Live- und Paneldaten. Jede Ansicht entscheidet selbst, welche Komponenten sichtbar sind. Vor dem ersten GSI-Paket kannst du bereits vorhandene Verwaltungsdaten aus managedMatch verwenden; Livewerte bleiben bis zum tatsächlichen Empfang leer oder als Wartezustand gekennzeichnet. Bedienfelder definierst du nach der Panelreferenz.

Komponenten mit echten Daten prüfen

Prüfe jede Komponente mit vorhandenen, fehlenden und veralteten Daten sowie nach einem Match- oder Seitenwechsel. Teamnamen, Logos, Kader und Wettbewerbsangaben stammen aus den Verwaltungsmetadaten; Spielstand und Spielerwerte aus den dafür vorgesehenen Livefeldern. Die HUD-API-Anleitung beschreibt Quellen und fachliche Grenzen.

Für einen Killfeed benötigst du tatsächliche Ereignisse aus der HLAE-Verbindung; leite keine Abschüsse aus veränderten Lebenspunkten ab. Ein Radar benötigt passende Kartendaten und bekannte Positionen. Fehlende Geometrie, Bilder oder Statistiken darf deine Darstellung nicht durch erfundene Werte ersetzen. Wähle und lizenziere die Gestaltung, Grafiken und Kartendaten deines Projekts selbst.

Ressourcen, Rechte und Vertrauensmodell

Die eigenen Bestandteile des sOU-SDK und die eigenen Vorlagen stehen unter der MIT-Lizenz. Du darfst sie auch für kostenpflichtige und geschlossene HUDs verwenden. Bei Weitergabe von SDK-Code müssen dessen Lizenz- und Urheberrechtshinweise erhalten bleiben; dein eigener HUD-Quellcode muss durch diese Lizenz nicht veröffentlicht werden. Mitgelieferte Fremdsoftware behält ihre jeweiligen Lizenzbedingungen.

Native HUDs beziehen Skripte, Schriften und Bilder aus ihrem Paket oder über die vorgesehenen lokalen Medienpfade. Die Hostrichtlinie erlaubt keine beliebigen externen Skripte oder Netzverbindungen. Beachte die Lizenzen deiner eigenen Abhängigkeiten und Grafiken; die SDK-Lizenz erteilt keine zusätzlichen Rechte an fremden Grafiken oder Gestaltungen. Lizenzhinweise des mitgelieferten SignalR-Clients müssen erhalten bleiben.

Importierte Pakete teilen eine lokale Origin. Paketprüfung und getrennte Paneladressierung sind keine Sandbox zwischen fremden Skripten. Verwende nur Pakete, deren Herkunft du vertraust. Das SDK stellt die lokale HUD-Verbindung ohne Zugangsdaten im Paket her. Kontopasswörter, Zugriffstokens und andere private Zugangsdaten gehören weder in Paketdateien noch in Browseradressen oder HUD-Logs. Das vollständige Datenmodell steht in der HUD-API-Referenz, Bedienfelder in der Panelreferenz.

Als Creator kannst du neue HUDs und unveränderliche Paketversionen auch über einen organisationsgebundenen API-Schlüssel hochladen. Einrichtung, Upload und Prüfstatus beschreibt die Creator-API-Anleitung.

Discord-Updates für dein HUD

Öffne in der Desktop-App HUDs → Veröffentlichen → Discord-Updates beim gewünschten HUD. Alle Publisher können dort ihre HUDs direkt mit Discord verbinden; ein Wechsel zur Website ist nicht erforderlich. Hinterlege je HUD eine eigene Discord-Webhook oder aktiviere zusätzlich „Im sOU-Community-HUDs-Kanal ankündigen“. Die zentrale Community-Webhook bleibt verborgen. Für den Community-Kanal muss das HUD öffentlich gelistet sein; private HUDs können ausschließlich die eigene Webhook verwenden.

Neue Versionen werden erst nach erfolgreicher Freigabe angekündigt. Ausstehende oder abgelehnte Uploads und frühere Versionen werden nicht nachträglich angekündigt. Die Meldung enthält HUD-Name, Version und die Patchnotes aus dem optionalen Manifestfeld releaseNotes. Längere Hinweise erscheinen vollständig in nummerierten Nachrichten. Änderungen der Ziele gelten für künftige Freigaben und verwerfen noch wartende ältere Ankündigungen. Ein leeres Webhook-Feld behält die gespeicherte Adresse; über „Gespeicherte Webhook entfernen“ löschst du sie. Gespeicherte Adressen werden verschlüsselt und nicht wieder angezeigt.

Fehlt die zentrale Verbindung, wartet der Versand auf die Einrichtung. Bei Discord-Ratenlimits wird später erneut versucht. Bei unklarer Empfangsbestätigung gibt es keine automatische Wiederholung; prüfe den Kanal. Die Discord-Einstellungen in der App zeigen fehlgeschlagene und unklare Sendungen an. Bei einem Änderungskonflikt aktualisiere die Ansicht und prüfe den aktuellen Stand, bevor du erneut speicherst.