sOU kann CS2-HUDs aus der gemeinsamen LHM-/JT’s-HUD-Manager-Familie direkt als ZIP importieren. Der Originalrenderer bleibt erhalten; sOU liefert die erwarteten Spiel-, Team-, Match- und Paneldaten über eine lokale Kompatibilitätsschicht. Du brauchst dafür keinen zusätzlich gestarteten LHM- oder JT-Manager.
Die Unterstützung bezieht sich auf das hier beschriebene CS2-HUD-Profil. Zusätzliche Dienste eines anderen Managers, etwa Spielerkameras, vMix oder dessen Cloud-/Premiumfunktionen, sind davon getrennt.
Original-ZIP importieren
- Eine fertig gebaute HUD-Ausgabe verwenden. An der ZIP-Wurzel müssen
hud.jsonundindex.htmlliegen; die benötigten Assets gehören ebenfalls ins Archiv. - Im Manifest muss
gameden Wertcs2haben.nameundversionmüssen vorhanden sein. - In sOU HUDs → Paket aus Datei importieren wählen und das Originalarchiv auswählen.
- Nach erfolgreichem Import das angebotene Panel konfigurieren und die Ausgabe über sOU öffnen. Für OBS die dort angebotene Adresse übernehmen.
- Das aktive Match, die Profile und die aktuelle Datenverbindung prüfen. Ein korrekt importiertes HUD kann ohne GSI, erforderliche Geometrie oder Matchzuordnung noch keine vollständige Live-Darstellung liefern.
Ein Quellcode-ZIP mit package.json und src ist nicht automatisch ein fertiges Browserpaket. Baue es zuerst nach den Anweisungen des HUD-Autors. Der sOU-Import führt keine npm-Skripte aus und installiert keine Entwicklungsabhängigkeiten.
Was beim Import geschieht
Ein Manifest ohne natives apiVersion-Feld, aber mit game, wird als Legacy-Manifest erkannt. Aus dem kleingeschriebenen HUD-Namen bildet sOU eine Kennung lhm-<name>; Folgen anderer Zeichen werden zu Bindestrichen und äußere Bindestriche entfernt. Der Namensanteil darf nach dieser Normalisierung 1–59 Zeichen lang sein.
Alle Originaldateien werden unter wwwroot übernommen. Darüber entsteht ein natives Manifest mit runtime: "lhm", apiVersion: 2 und entryPoint: "index.html". Ein vorhandenes thumb.png wird als Paketlogo verwendet. Bei Aktionsfeldern ohne label wird für den Editor der Feldname als Beschriftung ergänzt; die ursprüngliche Definition bleibt als panel.json.original erhalten. HTML, CSS und JavaScript des Renderers werden dabei nicht neu gestaltet oder neu gebaut.
Gleiche normalisierte Namen ergeben dieselbe Paketkennung, auch bei verschiedenen Autoren. Eine schon installierte Kombination aus Kennung und Version wird abgewiesen. Es gibt keine automatische Umbenennung, die zwei gleichnamige Pakete auseinanderhält. Vor einer Verteilung deshalb eindeutige HUD-Namen verwenden und für Änderungen neue Versionen vergeben.
Auch Original-ZIPs unterliegen den Archiv- und Pfadgrenzen. Innere Leerzeichen in Dateinamen sind erlaubt. Panel-Auswahlwerte wie 2.5em sind Datenstrings und zulässig; unbekannte Feldtypen oder ungültige Abschnittskennungen sind es nicht.
Normalisieren für Weitergabe und Cloud-Upload
Installiere das Paketwerkzeug über NuGet oder aus dem portablen SDK nach der Anleitung Vorlagen und Werkzeug einrichten. Lege original-hud.zip in das dort angelegte Arbeitsverzeichnis und führe aus:
./werkzeuge/sou-hud validate ./original-hud.zip
./werkzeuge/sou-hud normalize ./original-hud.zip ./ausgabe/mein-lhm-hud.souhudFür den lokalen Direktimport ist keine vorherige Umwandlung nötig. Die Cloud-Paketprüfung erwartet dagegen das native sOU-Format; dafür dient normalize. Das Ergebnis bewahrt die Originaldateien in der beschriebenen Pakethülle. Rechte zur Weitergabe und Lizenzen des HUD-Autors bleiben davon unberührt.
Unterstützter Umfang
| Bereich | Unterstützung | Präzise Grenze |
|---|---|---|
| Verbindung | Engine.IO 4, Socket.IO-Root-Namespace, HTTP-Polling, Registrierung, Heartbeats und erneute Registrierung nach Reconnect. | Kein WebSocket-Upgrade, Engine.IO 3, binäre Ereignisse, Acknowledgements oder weitere Namespaces. |
| Live-Spiel | Map, Runde, Seiten, Spieler, Waffen, Countdown, Bomben und unterstützte Granaten aus den vorhandenen sOU-Spieldaten. | Unvollständig darstellbare Snapshots werden nicht mit Ersatzwerten ergänzt; die benötigten Datenquellen müssen verbunden sein. |
| Teams und Spieler | Verwaltete Profile, Teamlogos und Spielerbilder über die erwarteten lokalen Routen. | Felder, die sOU nicht besitzt, werden nicht erfunden; Steam-Fotos werden nicht allein aus einer ID extern nachgeladen. |
| Match und Veto | Aktives Match, gespeicherte darstellbare Matches, explizite Vetos, Teamserienpunkte und Mapergebnisse. | Legacy-Matchformate bo1, bo2, bo3 und bo5. Ein BO7-Match wird nicht als BO5 ausgegeben. |
| Panels | Text, Schalter, Auswahl, Bilder/Bildlisten, Spieler-/Team-/Matchreferenzen und einmalige Aktionen. | Keine globalen Manager-Tastenkürzel, kein refreshHUD-Steuervertrag und keine automatische Funktionsergänzung im Originalbundle. |
| Radar | Mitgelieferte Kartenassets und verfügbare GSI-/HLAE-Geometrie. | Kein Import eines zentralen LHM-Custom-Mapkatalogs; Katalogrouten liefern leere Listen. |
| Killfeed | Echte HLAE-player_death-Ereignisse über update_mirv, ohne vergangene Kills bei Erstverbindung/Reconnect nachzuspielen. | Keine player_hurt-Übertragung und kein allgemeiner MIRV-Ereignisvertrag. |
| Kamera und vMix | Definierte leere Kameraliste. | Keine Kameraübertragung, WebRTC-Signalisierung oder vMix-Steuerung. |
| Turnier-/Anbieterdienste | Lokale Matchdaten für das HUD. | Keine LHM-Cloud-/Premiumdienste und kein Legacy-Turnierbaum; die Turnierroute liefert eine leere Liste. |
Adressierung und Socket.IO-Verhalten
Die von sOU angebotene stabile Adresse lautet /huds/{id}/. Sie lädt das Original unter /compat/huds/{id}/{version}/ und setzt isProd=1. Das verhindert bei den üblichen Vorlagen den Wechsel auf deren Entwicklungsserver. Verwende deshalb die von sOU angebotene Ausgabeadresse und keine hart codierte LHM-Entwicklungsadresse.
Die Kompatibilitätsrouten ordnen Root-API und Socket.IO über den same-origin Referer der geladenen inneren Adresse einer konkreten Paketversion zu. Neue Ausgaben können eine neue Version wählen; bereits geladene Ausgaben behalten ihre Version. API- oder Socketaufrufe aus einem fremden Dokument ohne passende Paketadresse sind keine zulässige Integration.
| Ablauf/Ereignis | Richtung | Bedeutung |
|---|---|---|
/socket.io/?EIO=4&transport=polling | Client ↔ Host | Engine.IO-Handschlag; der Host bietet keine Transport-Upgrades an. |
| Socket.IO-Verbindung zum Root-Namespace | Client → Host | Der Host bestätigt und sendet readyToRegister. |
started | Client → Host | Wird zusätzlich als Anforderung einer Registrierung akzeptiert; nach Reconnect nicht zwingend erforderlich. |
register | Client → Host | Die HUD-Identität muss {id}/{version} sein und das Spiel cs2. Weitere übliche Registrierungsargumente bleiben Teil des Vorlagenaufrufs. |
update | Host → HUD | Darstellbarer Legacy-Spielzustand als ein Argument. |
match | Host → HUD | Hinweis auf geänderten Matchkontext; bestehende Clients laden ihn über REST. |
hud_config | Host → HUD | Verschachtelte Panelwerte für die gebundene Paketversion. |
hud_action | Host → HUD | Objekt mit action und data für eine aktuelle Auslösung. |
update_mirv | Host → HUD | Unterstütztes neues HLAE-Todesereignis. |
registerAsHUD | Client → Host | Antwort playersCameraStatus mit leerer Liste; keine Kameraverbindung. |
Der Host verwendet Heartbeats mit ungefähr fünf Sekunden Abstand und begrenzte Verbindungen/Puffer. Ein HUD, das ausschließlich WebSocket erzwingt, kann das Pollingprofil nicht verwenden. Für neue sOU-HUDs ist das native SDK geeigneter als eine neue Anwendung auf dem Legacy-Protokoll.
REST-Routen des Kompatibilitätsprofils
| GET-Route | Antwort |
|---|---|
/api/match/current | Aktives zentral zugeordnetes Match im Legacy-Format oder null, falls nicht darstellbar. |
/api/match | Liste der darstellbaren gespeicherten Matches. Vorschauen verwenden die ausdrücklich gespeicherten Gegner A/B. |
/api/teams, /api/teams/{id} | Verwaltete Teams beziehungsweise ein Team mit _id, name, shortName, country, logo, extra. |
/api/teams/logo/{id} | Originale lokale Bildbytes mit passendem Inhaltstyp; fehlendes Bild ergibt 404. |
/api/players?steamids=id1;id2 | Profile; optionaler Semikolonfilter. Als Coach markierte Spieler werden ausgeschlossen. |
/api/players/avatar/steamid/{id} | Objekt mit custom für die vorhandene lokale Avatarreferenz und leerem steam. |
/api/huds/{id}/{version}/{section}/{field} | Lokale Bildbytes eines deklarierten einzelnen image-Felds der gebundenen Version; no-store. |
/api/camera | Objekt mit leerem availablePlayers-Array. |
/api/tournament, /api/radar/maps, /api/game-maps/cs2 | Leere Arrays; keine implementierten zentralen Kataloge. |
Alle Routen verlangen die lokale Browsersitzung und eine passende versionsgebundene Paketadresse als Referer. Unbekannte Routen ergeben 404. Die Antworten sind für den vorhandenen Legacy-Verbraucher gedacht; ein nativer Autor sollte stattdessen die typisierten sOU-Verträge verwenden.
Datenabbildung und Darstellungsgrenzen
Das HUD erhält die aufbereiteten sOU-Spieldaten im Legacy-Format. Vollständige GSI-Rohpakete und Authentifizierungsdaten werden nicht weitergegeben. Die Spielerrichtung und Position kommen bevorzugt aus passender HLAE-Geometrie, sonst aus vorhandenen GSI-Vektoren. Observer-Ziffern sind bereits 1…9,0; keine zusätzliche Umrechnung auf die rohen Valve-Indizes durchführen.
Ein neuer Legacy-Spielstand benötigt ein Spiel, mindestens einen Spieler, Map und Countdown. Außerdem braucht jeder ausgegebene Spieler eine Steam-ID und brauchbare Position/Richtung aus GSI oder Radar. Fehlen diese Voraussetzungen, wird kein neuer update-Frame gesendet. Ein Original-HUD kann deshalb seinen letzten Zustand weiter zeigen. Bei einer stehenden Anzeige zuerst Datenverbindung und Geometrie prüfen, nicht eine universelle automatische Leeranzeige erwarten.
Die zentrale Teamzuordnung bleibt maßgeblich. Bildschirmreihenfolge wird für den Renderer angepasst, erzeugt aber keine neue Identität. Fehlende oder widersprüchliche Zuordnungen bleiben im Matchformat offen. Originalrenderer können eigene Team- und Profilcaches besitzen; nach geänderten Namen, Fotos oder einem Identitätswechsel kann ein bewusstes Neuladen der Quelle erforderlich sein.
Der Host liefert kein zweites update-Argument mit rückwirkender serverseitiger Damage-/ADR-Rundenhistorie. Ein Legacy-Client kann eigene Statistiken erst ab seiner Verbindung sammeln. Er kann damit bei spätem Einstieg nicht automatisch die ganze Matchhistorie rekonstruieren.
Panels und Bilder im Legacy-Format
sOU speichert Panelwerte weiterhin in seinem nativen, versionsbezogenen Format. Bei der Übertragung werden einzelne Bilder und Bildlisten in die vom Legacy-Profil erwarteten Base64-Dateiinhalte übersetzt. Zusätzlich können Originalclients einzelne deklarierte Panelbilder über die REST-Route laden. Die gespeicherten lokalen Medienpfade werden dadurch nicht verändert.
Player-, Team- und Matchfelder werden als Wrapper { "player": … }, { "team": … } beziehungsweise { "match": … } übertragen. Ist das Objekt nicht mehr vorhanden, enthält der Wrapper null. Die üblichen Profilfelder werden aus der Bibliothek aufgelöst; fehlende Herkunftsangaben werden nicht erfunden.
Aktionen werden nur aktuellen Abonnenten der jeweiligen Version zugestellt. Nach Reconnect wird der Zustand erneut gesendet, keine vergangene Aktion. Ein im Panel deklarierter Button ist nur dann funktional, wenn das Originalbundle dessen Ereignis tatsächlich behandelt. Weitere Regeln zu Speichern und sofortigen Aktionen stehen unter Paneltransport und Wiederverbindung.
Externe Schriften und Bilder
Die LHM-/JT-Ausgaberoute erlaubt HTTPS-Stylesheets, HTTPS-Schriftdateien und HTTPS-Bilder; für Bilder sind außerdem Daten-/Blob-URLs möglich. Damit können Original-HUDs ihre eingebundenen Brandinggrafiken und Webfonts beziehen. Diese Fremdressourcen benötigen erreichbare Anbieter und Internetzugang.
Skripte und Live-Datenverbindungen bleiben auf die lokale Origin beschränkt. Ein Paket, das zusätzliche externe Skripte, einen fremden API-Server oder Formulare benötigt, erhält dadurch keine pauschale Freigabe. Native sOU-Pakete behalten ihre eigenen strengeren Regeln für lokale Assets. Importiere ausschließlich vertrauenswürdige HUDs; die gemeinsame Origin ist keine Isolation zwischen beliebigen fremden Skripten.
Probleme gezielt eingrenzen
- Import scheitert: Gebautes Archiv, CS2-Manifest, Namens-/Versionskollisionen, Pfad- und Panelgrenzen prüfen.
- Assets fehlen: Relative Pfade und tatsächliche Dateien im ZIP prüfen; bei HTTPS-Ressourcen Erreichbarkeit des ursprünglichen Anbieters prüfen.
- Keine Registrierung: Ausgabeadresse von sOU verwenden,
isProd=1und Socket.IO-Polling statt eines fest verdrahteten Entwicklungsservers prüfen. - Verbindung steht, Anzeige wartet: GSI, Countdown, Spielerpositionen und aktive Matchzuordnung kontrollieren.
- Alte Namen/Bilder: Quelle neu laden, wenn der Originalrenderer Metadaten zwischenspeichert.
- Button ohne Wirkung: Prüfen, ob das Original-HUD die konkrete Aktion verarbeitet; der Import ergänzt keine fehlende Rendererfunktion.
Für die allgemeine Ausgabe- und OBS-Einrichtung siehe HUD-Ausgabe. Wenn du den Quellcode eines HUDs ohnehin neu entwickelst, bietet die native API die vollständigen sOU-Zustände ohne die zusätzlichen Grenzen der Legacy-Projektion.