Bisher entschied `x.gamedig` darueber, ob aus einem Panel-Server ein
Monitor-Eintrag wird: "kennt unsere Bibliothek dieses Spiel?" Das hat
einen Fall ausgesperrt, den es wirklich gibt -- TeamSpeak.
UND ZWAR NICHT, WEIL GAMEDIG ES NICHT KOENNTE. Am 16.08.2026
nachgeschlagen, nachdem die Annahme "gamedig kennt TeamSpeak nicht"
sich als falsch erwies: gamedig 5.3.3 hat `teamspeak3`, DiscordGSM
fuehrt es ebenfalls. Der Grund ist ein anderer und ein besserer:
node_modules/gamedig/protocols/teamspeak3.js
queryPort = options.teamspeakQueryPort || 10011
'use port=<voice>' -> 'serverinfo' -> 'clientlist'
Es braucht den SERVERQUERY-Port. Beim Betreiber liegt der hier:
9987/udp -> 0.0.0.0:9987 Sprache, oeffentlich
10011/tcp -> 127.0.0.1:9988 ServerQuery, NUR localhost
30033/tcp -> 0.0.0.0:9989 Dateien, oeffentlich
Der Bot laeuft im Container und erreicht 127.0.0.1 des Hosts nie. Zwei
Gegenproben vom Host aus, beide gescheitert (die zweite auch deshalb,
weil gamedig ohne `teamspeakQueryPort` stur 10011 nimmt -- den es dort
gar nicht gibt). Eine Kennung einzutragen brauechte also einen OFFENEN
Verwaltungsport, und das ist genau das, was die Regel "kein Port geht
ohne Eintrag ins Netz" verhindert.
Das Panel dagegen laeuft auf dem Host, darf hin und hat die
Zugangsdaten -- und schickt seine eigene Messung seit heute im
Statusbericht mit. Also:
- `taugt` fragt `zeigbar` statt `gamedig`: "kann UEBERHAUPT JEMAND
diesen Server abfragen -- wir oder das Panel fuer uns?" Mit
Rueckfall auf `gamedig` fuer ein aelteres Panel; ohne den
verschwaenden nach diesem Update alle Eintraege, und zwar lautlos.
- Neuer eigener Typ `panel` neben `fivem` und `http`. Er ersetzt
nichts: wo gamedig kann, bleibt es bei gamedig -- dessen Antwort
bringt Karte, Fassung und Ping mit, die das Panel nicht liefert.
- `spieler === null` heisst KEINE ANTWORT, nicht null Spieler. Das
Panel sichert dazu einen Grund zu; wir werfen damit und landen im
selben Zweig wie ein gescheiterter gamedig-Query, statt eine 0 zu
erfinden. Und kein Ping: die Zahl ist eine gespeicherte Messung des
Panels, keine Antwortzeit von hier.
EINE FALLE BEIM ZWEITEN PARAMETER: `servers.map(queryServer)` haette
`panelItems` den INDEX untergeschoben -- der erste Server saehe null,
alle weiteren eine Zahl, an der `panelEintrag` still scheitert. Also
`map((s) => queryServer(s, panelItems))`.
Probe erweitert und im neu gebauten Abbild gelaufen, alles gruen --
einschliesslich "null Spieler sind eine Antwort, kein Ausfall".
Der Betreiber hat im Panel den Schalter fuer atm11-test umgelegt und im
Discord passierte nichts. Er hat den Fehler bei sich gesucht -- ob er den
Namen falsch geschrieben habe. Hat er nicht: der Server stand schon von
Hand im Monitor, weil ich ihn vorhin selbst dort eingetragen hatte, und
der Abgleich uebersprang ihn mit `continue`, damit nicht zwei Embeds fuer
denselben Server im Kanal stehen.
Das Ueberspringen war richtig, das Schweigen nicht. Wer den Schalter
umlegt, sagt "dieser Server gehoert ans Panel" -- also bekommt der
bestehende Eintrag jetzt den Herkunftsvermerk, statt ignoriert zu werden.
Ein zweites Embed entsteht dabei nicht.
Der Preis gehoert benannt und wird mitgeprueft: ab der Uebernahme nimmt
ein Ausschalten den Eintrag mit, samt Bild und Links, die von Hand daran
haengen. Das ist der Sinn des Schalters, aber es ist eine Uebertragung
von Besitz.
Ueberschrieben wird weiterhin kein Feld -- die Uebernahme setzt nur
panel_name.
Und die Meldung im Protokoll unterscheidet jetzt "neu" von "uebernommen";
vorher hiess beides "uebernommen", was genau die Auskunft verwischt haette,
um die es hier geht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Im d4rk_gameserver-Panel bekommt jeder Server einen Schalter "Im Discord
anzeigen". Das Panel schreibt dafuer NICHTS hierher: es setzt nur ein
Haekchen, und das reist in dem Statusbericht mit, den der Monitor ohnehin
alle 30 Sekunden abholt. Der Bot legt den Eintrag dann selbst an.
Der umgekehrte Weg -- Panel ruft unsere API -- braeuchte dort ein
Zeichen mit Schreibrecht. So bleibt es bei einem, das nur lesen kann.
ZWEI FALLEN, beide beim Bauen aufgefallen:
Der Abgleich lief zu spaet. In monitorTick stand `if (servers.length ===
0) return` VOR dem Panel-Abruf; beim allerersten Server haette der
Schalter also nichts getan, und zwar stillschweigend. Der Abruf steht
jetzt davor.
Loeschen braucht einen Besitzvermerk. Ohne den nimmt ein Haekchen im
Panel den handgepflegten ATM10 mit -- die einzige verfuegbare Grundlage
waere der Name, und beim ersten Server, der in beiden Werkzeugen gleich
heisst, waere der Eintrag samt Bild, Links und Zugangs-Code weg. Neue
Spalte `panel_name`, leer heisst "von Hand". Die UPDATE-Anweisung fasst
sie nicht an, damit ein Bearbeiten im Webinterface die Herkunft behaelt.
Und der Abgleich ueberschreibt nichts: angelegt und geloescht wird, mehr
nicht.
tools/panel-abgleich-pruefen.mjs prueft das auf einer EIGENEN Datenbank
in /tmp und bricht ab, wenn sie es nicht ist -- eine Probe, die loeschen
kann, darf nicht dort loeschen, wo es zaehlt. Alles gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
D4rkst3r
