6 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
svennickel	2c4b3e0908	Spielpunkte-Wertung neben die Einheit, die sie uebernimmt ... Sven 2026-09-08: „hier wuerde ich die Option direkt unter ‚Saetze pro Spiel' ziehen und abhaengig von der Einstellung bei ‚Saetze pro Spiel' benennen". Die vierte Wertung („ohne Umrechnung") uebernimmt das Spielergebnis als Spielpunkte — welche Zahl das ist, sagt aber ein ANDERES Feld: Tore bei „Einer", Saetze bei „Mehrere". Sie stand bisher zwei Gruppen weiter oben unter „Begegnung", also getrennt von der Angabe, die ihre Bedeutung festlegt. - „Spielpunkte pro Spiel" (Einzel + Doppel) sitzt jetzt direkt unter „Saetze pro Spiel" in der Gruppe „Spiel" — wo sie hingehoert: es ist eine Angabe zum einzelnen Spiel, nicht zur Begegnung. „Begegnung abgeschlossen bei" bleibt in der Gruppe „Begegnung". - Der Eintrag heisst jetzt nach der gewaehlten Einheit: „Ohne Umrechnung – Saetze sind die Spielpunkte" bzw. „… Tore sind die Spielpunkte". Ueber dasselbe data-tore/data-saetze-Verfahren, das die Siegbedingungen schon benutzen; umgeschaltet in zeilen_anzeigen(), also auch beim Wechseln ohne Neuladen. Der alte Sammeltext bleibt als Rueckfall stehen. - Am lokalen Testserver gerendert und geprueft: Reihenfolge stimmt, beide Texte kommen uebersetzt an. - Nebenbei: der Kommentar nannte Datenbankversion 126, tatsaechlich ist es 122.	2026-09-08 16:08:44 +02:00
svennickel	84211e9f9e	Ergebnisanzeige, Spielerstatistik, und die Spielfolge bleibt schmal ... Drei weitere Punkte aus dem Review. 1. ERGEBNISANZEIGE BEI SAETZEN. Im Spielbericht stand je Spiel NUR ergebnis_detailliert. Bei reinem „Mehrere" ist das derselbe Satzstand — bei Erfassung je Satz sind es die Saetze, und dann fehlte, wer das Spiel gewonnen hat. Gemessen: die Zeilen lasen „6:3 | 3:6" ohne jede Angabe des Standes. Jetzt steht der Stand davor und die Saetze in Klammern dahinter: „1:1 (6:3 | 3:6)", „2:1 (6:3 | 3:6 | 6:4)". Wo beides dasselbe ist („Einer", oder „Mehrere" ohne Satzerfassung), bleibt es einzeilig — gegengeprueft an einer Begegnung aus der Einer-Zeit: unveraendert „6:3", nichts doppelt. Ein nicht gespieltes Spiel bleibt leer und zeigt kein „0:0". 2. SPIELERSTATISTIK. Die Spalten „T +/-" summieren teamspiel_*_punkte, zaehlen also je punktetyp Tore oder gewonnene Saetze — hiessen aber immer „Tore". Anders als in der Tabelle gibt es hier nicht einen Modus: eine Bestenliste kann mehrere Wettbewerbe umfassen, sogar Individualwettbewerbe. spielerstatistikEinheit() liest deshalb den punktetyp der speisenden Wettbewerbe; sind sie einig, steht die richtige Einheit, sonst „Punkte" — statt eine zu behaupten, die nicht fuer alle Zeilen gilt. Neuer Schluessel COM_SPORTSMANAGER_SETS_SHORTCUT in beiden Sprachen. Alle drei Faelle gemessen: nur „Mehrere" -> „S +/-" mit „Saetze", gemischt -> „P +/-" mit „Punkte", zurueck -> wieder „S". Und der Tooltip der Tabellenspalte hiess COM_SPORTSMANAGER_DIFFERENCE = „Differenz Tore", widersprach also der neuen Beschriftung „Saetze". Er nennt jetzt nur die Rechenart („Differenz"), wie sein Geschwister „Verhaeltnis" schon immer; die Einheit steht in der Spalte. Einzige Verwendungsstelle. 3. SPIELFOLGE. Die sechs Auswahlfelder der Spielfolge und der Verknuepfungen stehen wieder auf medium — sie tragen kurze Werte und sollten nicht mitwachsen. Breit bleiben nur die 33 Felder der Einstellungen, wo die langen Beschriftungen stehen.	2026-09-07 18:01:58 +02:00
svennickel	099174c0ef	Tabellenspalte richtig benennen: bei „Mehrere" sind es Saetze, keine Tore ... Aus dem Review: „Die Summe der Tore ist auch falsch." Sie ist es nicht — sie ist falsch BESCHRIFTET. Unter punktetyp „Mehrere" ist begegnung.heim_punkte seit immer die Summe der Satzstaende, und die Tabellenspalte heisst „Tore". Bisher fiel das nicht auf, weil die Tore gar nicht bekannt waren; mit der Erfassung je Satz sind sie es, und die Spalte behauptet etwas, was sie nicht zeigt. Die Absicht war schon da: tabelleAnzeigen() fragt `punktetyp != 2 ? Tore : Saetze` — nur kennt punktetyp ausschliesslich 0 und 1, die Bedingung war also nie wahr. Jetzt `punktetyp == 0 ? Tore : Saetze`, an beiden Spaltenkoepfen (Absolut und Differenz/Verhaeltnis). Gemessen an zwei Wettbewerben derselben Installation: bei punktetyp 1 stehen jetzt „Saetze Absolut" und „Saetze", bei punktetyp 0 unveraendert dreimal „Tore". Keine Zahl aendert sich, kein Sortierschluessel, keine Bestandsdaten. Die Alternative — die echten Tore summieren, wo Satzergebnisse geführt werden — waere ein Eingriff in Bestandsstaende und in die Tabellensortierung und gehoert in einen eigenen PR mit Migration (Sven 2026-09-07).	2026-09-07 13:52:35 +02:00
svennickel	554ad25156	Review: Unentschieden nur, wo es moeglich ist; Kommentare gekuerzt; Felder breiter ... Drei Punkte aus dem Review. 1. UNENTSCHIEDEN, WO ES KEINES GIBT. Gemeldet: „2 Punkte pro Spiel und 1 Punkt unentschieden ausgewaehlt, es kommt aber nur 1 Punkt pro Spiel." Nachgestellt an einer Begegnung mit vier Spielen (Modus: Mehrere, Ergebnis je Satz, 3 Gewinnsaetze, Wertung „Sieg 2, Remis 1"): Spiel 1 mit 6:3 3:6 steht 1:1 nach Saetzen und bekam 1:1 Spielpunkte. Bei einer Zahl von GEWINNSAETZEN ist ein gleicher Satzstand aber kein Unentschieden, sondern ein unfertiges Spiel — dafuer gibt es keinen Punkt. Die Rechnung fragt jetzt, ob der Modus ueberhaupt ein Remis zulaesst: bei Gewinnsaetzen nein, bei fester Satzzahl nur bei gerader Zahl, ohne Angabe wie bisher. Gemessen an derselben Meldung: Spiel 1 jetzt 0:0, die Begegnung 6:0 statt 7:1; die Spiele 2 bis 4 unveraendert 2:0. Die Rechnung selbst ist Altbestand und von diesem PR nicht angefasst — erst die neue Satzzahl liefert die Information, mit der sie unterscheiden kann. 2. KOMMENTARE. Zu Recht beanstandet. Was Sprachmechanik erklaert oder den Code nacherzaehlt, ist raus; was eine Entscheidung oder einen Messwert festhaelt, bleibt in hoechstens drei Zeilen. Die Herleitung gehoert in den PR-Text, nicht in die Datei. update.php von 87 auf 22 Kommentarzeilen (57 % auf 25 % der Aenderung), ueber alle Dateien von 459 auf 267. 3. AUSWAHLFELDER. Die 39 Auswahlfelder des Modus-Formulars stehen von medium (200 px) auf large (500 px). Bei 200 px brach eine Beschriftung wie „Ohne Umrechnung - Tore bzw. Saetze sind die Spielpunkte" ab. Nur dieses Formular, keine andere Ansicht. Danach geprueft: sechs Ansichten HTTP 200 ohne PHP-Meldung, php -l sauber, dieselbe Meldung mit dem erwarteten Ergebnis.	2026-09-07 13:30:21 +02:00
svennickel	09ae1c1609	Siegbedingungen vollstaendig abbilden, samt Race-Modus (#304) ... Vorsprung und Deckelung je Spiel, dieselbe Regel eine Ebene tiefer fuer den einzelnen Satz, eine Auswahl der Satzzahl (feste Zahl oder Gewinnsaetze) samt optional abweichender Regel fuer den Entscheidungssatz, eine Auswahl "Mehrere - mit Ergebnis je Satz" mit Satzzeilen im Begegnungsformular — und eine Zaehlweise "Race-Modus", in der der Stand ueber die ganze Begegnung durchlaeuft. Die Regel beschreibt den Wettbewerb, sie lehnt keine Eingabe ab: ein 8:6 dort, wo ein Spiel bei 6 endet, hat oft einen Grund, den keine Regel kennt, und ueber die Richtigkeit wachen beide Mannschaften. Ihr Nutzen liegt darin, dass eine auswertende Anwendung endlich erkennen kann, ob ein Spiel entschieden ist. RACE-MODUS. Das Spiel N endet, wenn der LAUFENDE Stand einer Seite N mal den Schritt erreicht; eingetragen wird wie bisher die DIFFERENZ dieses Spiels, und der Begegnungsstand bleibt ihre Summe. Gemessen an 91 Bundesliga-Begegnungen: 6:5 5:7 7:5 4:7 8:2 6:9 6:5 summiert sich auf 42:40, und laufend gelesen trifft jedes Spiel seine Etappe (6, 12, 18, 24, 30, 36, 42). Die Ergaenzung im Formular rechnet deshalb mit laufenden Staenden und zieht ab, was schon auf dem Konto steht. Im Formular steht statt des gespeicherten "Zwischenergebnis" jetzt der GESAMTSTAND, gross und in Echtzeit: die Spielpunkte, gerechnet aus den eingetragenen Spielen mit derselben Arithmetik, die der Server beim Speichern anwendet. Es ist DIE Zahl, die die Begegnung nach aussen hat — Liste, Mannschaftsseite und die Kopfzeile der Begegnungsdetails zeigen alle heim_spielpunkte:gast_spielpunkte. Gemessen an einem 5er-Spielplan mit "Sieg: 1 Punkt": ein eingetragenes 6:4 ergibt "1:0", genau wie die Details. Die Torsumme gehoert dagegen in die Tabellenspalte "Tore" und nicht in den Kopf einer Begegnung. Die Zeile steht als letzte des Kopfes, unter dem Kommentar, mit demselben senkrechten Abstand, den die Spiele untereinander haben — und ohne erklaerenden Zusatz: "Gesamtstand" samt Zahl sagt es selbst. Das Ziel wird nicht eingegeben, sondern folgt aus der Spielfolge. Dort steht deshalb die Rechenvorschrift ("Anzahl der Spiele aus der Spielfolge x Schritt je Spiel") und die konkrete Zahl erst ab zwei Spielen ("derzeit 7 Spiele x 6 = 42 Tore"): bei einem einzigen — dem Anfangszustand — waere "1 Spiele x 6 = 6 Tore" nicht nur ungrammatisch, sondern eine Auskunft ueber einen Zustand, den niemand gemeint hat. Mindestvorsprung, Grenze und ein moegliches Unentschieden gelten nur fuer das letzte Spiel. Die Zaehlweise setzt "Spielergebnis als Spielpunkte" und einen Satz je Spiel voraus und setzt beides mit; das Ziel wird zusaetzlich nach punkte_sieg_* gespiegelt (mit Vorzeichen fuer das Unentschieden), damit eine aeltere Programmfassung dieselbe wahre Aussage liest. Vorrunde und Hauptrunde sind zwei Mannschaftsspielplaene. Die Zaehlweise steht als erste Zeile ihrer Gruppe: was sie ausblendet, liegt darunter — Felder ueber einer Auswahl verschwinden zu lassen, liest sich als Fehler. Damit die Einstellungen ueberhaupt auseinanderzuhalten sind, steht dem Editor eine kurze Begriffsleiter voran: Begegnung, Spiel, Satz, Tor. Sie stecken ineinander, und die Gruppen darunter folgen genau dieser Reihenfolge. Drei weitere Hinweiszeilen sagen, was "Ergebnis je Satz" bedeutet, wozu die Angaben gut sind und wie der Race-Modus zaehlt. Die vierte Spielpunkte-Wertung hiess "Keine" und sagte damit das Gegenteil dessen, was sie tut: gewertet wird alles, nur ohne Umrechnung — das Ergebnis des Spiels IST sein Spielpunktestand. Sie heisst jetzt "Ohne Umrechnung - Tore bzw. Saetze sind die Spielpunkte"; die drei uebrigen beginnen mit "Sieg:", also sagt schon der Satzanfang, dass es hier nicht um einen Sieg-Wert geht. Die Hinweiszeilen brechen ausdruecklich um und haben ein Mass (max-width): die Zellen dieses Formulars tragen alle `nowrap`, was fuer Beschriftungen und Auswahlfelder richtig ist und fuer Prosa falsch — die Hinweise zogen die Tabelle sonst beliebig breit. Wo ein Hinweis steht, ist die Beschriftung oben ausgerichtet: sonst stand sie auf halber Hoehe des Absatzes statt neben dem Auswahlfeld, zu dem sie gehoert. Die Satzebene fuehrt dasselbe Vorzeichen wie die Spielebene: der Betrag ist der Siegwert, ein negatives Vorzeichen erlaubt zusaetzlich ein Unentschieden ein Tor darunter. Ohne diese Faelle waere ein Satz, der remis endet, gar nicht hinterlegbar gewesen. Bestehende "Mehrere"-Modi werden in die Satzzahl UEBERFUEHRT, und zwar restlos: 1 wird ein fester Satz, ein positiver Wert N werden N Gewinnsaetze, ein negativer wird die feste Satzzahl 2(|N|-1) — denn ein Remis setzt voraus, dass alle Saetze gespielt werden. Auch Werte jenseits der neuen Auswahl werden ueberfuehrt statt als "Beliebig" liegen zu bleiben, denn sie sind nicht unsinnig, nur ungewoehnlich: ein gespeichertes "Spiel gewonnen bei 42 Saetzen" bleibt nach der Ueberfuehrung dieselbe wahre Aussage, nur an der richtigen Stelle. Das Formular zeigt einen solchen Wert als EIGENEN, vorgewaehlten Eintrag der Auswahl ("42 Gewinnsaetze"), speichert ihn unveraendert wieder und bietet ihn, einmal weggestellt, nicht mehr an. Sonst haette dort eine Zeile ohne Auswahlfeld gestanden — die Beschriftung "Spiel abgeschlossen bei:" und rechts daneben nichts — oder die Zahl waere beim ersten Speichern verschwunden. Gemessen an drei Bestandswerten: 42 wird -42 und uebersteht Anzeige und Speichern unveraendert, -9 wird die feste Satzzahl 16, und nach dem Wechsel auf "3 Gewinnsaetze" hat die Auswahl 18 statt 19 Eintraege. Der Race-Modus wird NICHT automatisch erkannt; er ist aus Bestandsdaten nicht sicher abzuleiten und wird einmal von Hand gewaehlt. Dass die Ueberfuehrung nichts verschiebt, ist gemessen und nicht bloss begruendet: dieselbe Datenbank einmal unter der alten Fassung mit altem Schema und einmal unter dieser, je sieben Begegnungen unveraendert neu gespeichert und dann Tabellen, Uebersicht, Spielerstatistik und drei Begegnungsdetails verglichen — 7942 Zeilen HTML und 436 Datenzeilen aus begegnung und teamspiel, kein einziger Unterschied. Darunter der Bestandsmodus mit punkte_sieg 42, den die Ueberfuehrung anfasst. Umgekehrt spiegelt der Editor die Satzzahl VOLLSTAENDIG nach punkte_sieg_* zurueck, nicht nur bei Gewinnsaetzen: eine feste Satzzahl sagt genau, welche Endstaende es gibt, und damit auch, bei welchem Stand das Spiel entschieden ist — 4 feste Saetze heissen "gewonnen bei 3, Unentschieden bei 2:2" (-3), 3 feste Saetze "gewonnen bei 2" (2). Das ist die Umkehrung der Ueberfuehrung und deshalb verlustfrei. Zuvor blieb punkte_sieg_* bei fester Satzzahl leer, mit der Begruendung, sie sei keine Siegbedingung — richtig gedacht, aber praktisch falsch: ein Client, der nur die alten Felder kennt, haette nach einmaligem Oeffnen und Speichern eines Bestandsmodus "Beliebig" gelesen, wo vorher eine Zahl stand. Und es gibt einen solchen Client, den wir nicht mitziehen koennen (Kickern). Gemessen: feste Satzzahl 4 -> -3, 3 -> 2, 6 -> -4, 1 -> 1, und Gewinnsaetze unveraendert 3 -> 3, 2 -> 2. Die Einheit der Spielebene folgt punktetyp: Tore bei "Einer", Saetze bei "Mehrere". Bisher stand dort in beiden Faellen "Punkte" — und genau daran war eine Fehlkonfiguration nicht zu erkennen. Am echten TFVB-Spielplan 2026 sah man es doppelt: "Spiel abgeschlossen bei 5 Punkte" direkt ueber "Mindestvorsprung 2 Tore", dieselbe Einheit in zwei Woertern. Innerhalb eines Satzes wird ohnehin durchgaengig von Toren gesprochen. Und "Spiele in Spielerstatistik" waehlt "Alle Spiele" jetzt ausdruecklich vor, statt sich darauf zu verlassen, dass es die erste Option ist. Aus "Vorsprung" wird "Mindestvorsprung" (und der Wert 1 heisst "Keiner"), aus "Deckelung" wird "Spaetestens gewonnen bei". Die Einstellungen sind in fuenf Gruppen geordnet, vom Grossen ins Kleine: Allgemein, Begegnung, Spiel, Satz, Spieler und Statistik. Dafuer wechseln drei bestehende Zeilen den Platz — "Aktiv" nach oben zu "Bezeichnung", "Spielernamen" hinunter zu "Spiele in Spielerstatistik", und die Gruppe "Begegnung" vor die Gruppe "Spiel"; sonst ist nichts verschoben. Der Knopf "Doppel getrennt einstellen" bekommt eine eigene Zeile, weil er auch die Satzregel schaltet. Eine Gruppe ohne sichtbare Zeile zeigt keine Ueberschrift. Die Spielfolge zeigt nur noch die Zeilen, die es gibt: Spiel 1 steht fest, weitere kommen ueber "Spiel hinzufuegen", jede weitere traegt ein Kreuz zum Entfernen — ohne Rueckfrage, denn gespeichert ist bis zum Speichern nichts. Verknuepfungen fangen bei null an. Alle Zeilen bleiben im Dokument und werden beim Entfernen nach oben geschoben, weil das Speichern spiel_1, spiel_2 … der Reihe nach liest und beim ersten leeren Paar abbricht. Das Ziel des Race-Modus rechnet dabei mit: es haengt an der Zahl der Spiele, und die aendert sich hier. Bei "Mehrere" beantwortet die Satzzahl die Frage vollstaendig — "Spiel abgeschlossen bei" wird dort deshalb gar nicht mehr angeboten. Es geht dabei nichts verloren, weil jeder Bestandswert in die Satzzahl uebergeht (siehe oben) und ein Wert jenseits der Auswahl dort als eigener Eintrag steht. Ohne geforderten Mindestvorsprung endet ein Spiel exakt beim Siegwert — eine Grenze kann dann nie greifen. "Spaetestens gewonnen bei" wird deshalb ueberall nur noch angeboten, wo ein Vorsprung verlangt ist, und beim Speichern auf null gesetzt. Die Spielfolge steht schon in derselben Spalte unter den Einstellungen und bekommt deshalb nur ihre Ueberschrift — als sechste Gruppe. Und "Spiele in Spielerstatistik" stellte nackte Zahlen neben "Alle Spiele"; sie sagen jetzt, was sie zaehlen ("nur die ersten 3 Spiele"). Beim WECHSEL der Satzart wird nichts umgerechnet — aus sechs Toren wuerden sechs Saetze, und umgekehrt; aus "drei gewonnene Saetze" folgt keine Torzahl, es ist also gar nicht rekonstruierbar. Stattdessen zwei Massnahmen. Erstens fragt der Editor nach, wenn "Saetze pro Spiel" geaendert wird und unter dem Spielplan schon Ergebnisse stehen. Zweitens ueberleben echte Satzergebnisse den Weg zurueck von "mit Ergebnis je Satz" auf "nur der Satzstand": bringt ein Aufruf keine Satzfelder mit, bleibt der Stand unveraendert und stehen im Bestand mehr als ein Paar, bleibt ergebnis_detailliert, wie es ist — sonst haette blosses Oeffnen und Speichern "6:3 3:6 6:3 3:6 8:6" durch "3:2" ersetzt. Wird der Stand geaendert, wird der Detailtext wie bisher neu geschrieben. RUECKWAERTSKOMPATIBEL, und zwar geprueft und nicht bloss behauptet. EINE Datenbankversion, 122, nicht sechs (Sven 2026-09-03): alle Spalten in einem ALTER, die Ueberfuehrung dahinter, ein Zaehler hoch. 121 gehoert dem Hall-of-Fame-Zweig (PR #303 / Issue #300), auf dem dieser Stand aufsetzt; dieser Block muss deshalb der LETZTE der Kette bleiben — $datenbank_version wird einmal gelesen, beide Bloecke laufen also im selben Aufruf, aber die Nummer des zuletzt gelaufenen bleibt stehen. Gemessen gegen eine Datenbank, die #303 schon hinter sich hat: 121 -> 122, unsere 24 Spalten dazu, die drei Hall-of-Fame-Spalten unberuehrt, der Bestandsmodus mit punkte_sieg 42 als saetze_modus -42 ueberfuehrt. Die Zwischenstufen waren nur die Reihenfolge, in der ich gebaut habe — kein Bestand hat sie je gesehen, und sechs Schritte, die immer zusammen laufen, sind sechs Gelegenheiten, auf halbem Weg stehenzubleiben. Gemessen an einer Datenbank auf Stand 120: ein Aufruf, 120 -> 122, 13 Spalten -> 37, der Bestandsmodus mit punkte_sieg 42 als saetze_modus -42 ueberfuehrt; ein zweiter Lauf tut nichts (die Spaltenpruefung und das WHERE der Ueberfuehrung sehen beide, dass es schon geschehen ist). Ein Client, der nur die ueberlieferten Felder liest, soll weiterarbeiten wie bisher — es gibt mindestens einen, den wir von hier aus nicht mitziehen koennen (Kickern). Dafuer zaehlt nicht, was hinzukommt, sondern was sich an dem aendert, was er schon liest. Neue Spalten sind harmlos: die Modus-Zeile geht als ganzes Objekt in die JSON-Ansicht, unbekannte Schluessel ignoriert jeder Client. Die Ueberfuehrung selbst fasst kein altes Feld an. Bleiben zwei Stellen, und beide sind versorgt. Erstens der Wertebereich von punktetyp. "Mehrere - mit Ergebnis je Satz" war zuerst ein dritter Wert 2 — und punktetyp ist genau das Feld, an dem eine fremde Anwendung ablesen muss, ob die Punkte eines Spiels Tore oder gewonnene Saetze sind. Wer "1 = Saetze, sonst Tore" schreibt statt "0 = Tore, sonst Saetze", haette bei einem Satzstand 3:2 "3:2 Tore" gelesen; beide Fassungen stehen im Sports Manager selbst. Die Angabe bekommt deshalb eine EIGENE Spalte (satzergebnisse), punktetyp behaelt seine zwei Werte und seine Bedeutung. Ein Altclient liest weiter "Mehrere" und rechnet richtig — die Punkte SIND die gewonnenen Saetze, daran aendert die feinere Erfassung nichts; er verpasst nur das Zusaetzliche. Die Auswahl im Editor hat weiter drei Eintraege, der dritte schreibt punktetyp 1 samt satzergebnisse 1. Zweitens: der Server verlangt die Satzergebnisse NICHT, auch wo sie eingestellt sind. Er fragt beim Speichern ueberhaupt nicht nach dem Modus — kommt kein Satzfeld mit, gilt der Summenwert, wie immer. Gemessen an einem Spielplan mit "3 Gewinnsaetze" und Satzerfassung, gemeldet wie ein Altclient nach SetsMode.setsOnly (nur spiel_N_*_punkte, keine Satzfelder): Spiel 1 als 3:1 gespeichert, Spielpunkte 1:0, ergebnis_detailliert "3:1" — genau die Zeile, die das eigene Formular unter "Mehrere" auch schreibt. Dieselbe Begegnung nimmt gemischt beides auf: Spiel 1 als Satzstand, Spiel 2 als "6:3 3:6 6:4". Meldet der Altclient danach beide Spiele erneut als Satzstand, ueberleben die Satzergebnisse von Spiel 2 unveraendert; dasselbe beim Oeffnen und Speichern im Verbandsformular, das fuer diesen Modus nur Satzzeilen zeigt — es belegt sie fuer Spiel 1 bewusst nicht vor (aus "3:1" folgt kein erster Satz) und schickt den gespeicherten Stand im versteckten Summenfeld mit. Nur wenn der Altclient das Spiel AENDERT, weicht der Detailtext dem neuen Stand ("2:0") — er beschrieb dann ein anderes Ergebnis. Und wo Satzergebnisse gefuehrt werden, bleibt ergebnis_detailliert bei einer Meldung ohne Satzfelder LEER, statt wie sonst den Stand zu spiegeln. Dieses eine Paar bedeutet dort naemlich etwas anderes als sonst: das Feld fuehrt Saetze, also liest man „3:1" als einen Satz mit drei Toren und rechnet daraus 1:0 statt 3:1 — in unserer eigenen App steckte genau dieser Fehler. Leer ist die Wahrheit: der Satzstand steht in teamspiel_*_punkte, die Tore darin sind nicht bekannt, und die Anzeige laesst die Detailspalte dann weg statt denselben Wert zweimal zu zeigen. Erfundene Platzhalter („1:0" je gewonnenen Satz) waeren die Alternative und sind verworfen: gespeichert liesse sie niemand mehr von einer echten Meldung unterscheiden (Sven 2026-09-03). Es ist die einzige Stelle, an der das Speichern nach dem Modus fragt. Gemessen: dieselbe Altclient-Meldung schreibt unter „Mehrere" weiter „4:2" und unter „Mehrere - mit Ergebnis je Satz" nichts; echte Satzergebnisse daneben bleiben unberuehrt, auch nach erneuter Summenmeldung und nach Oeffnen und Speichern im Formular. Der Race-Modus braucht dafuer nichts: fuer einen Altclient sieht ein Race-Spielplan aus wie punktetyp 0, "Ergebnis als Spielpunkte" und punkte_sieg = Ziel — also genau so, wie ein solcher Spielplan heute schon eingestellt ist. Er verliert nichts und gewinnt nichts. Die Spielerauswahl erscheint nur noch fuer eine Mannschaft, die auch Spieler hinterlegt hat — sonst stand dort ein Feld mit nichts als dem Leereintrag und behauptete eine Wahl, die es nicht gibt. Gespeichert wird dann genau wie bei einer leeren Auswahl: der Server liest die fehlenden Felder mit Vorgabe 0, also "kein Spieler". Die Absende-Pruefung wird SEITENWEISE erzeugt und liest nur, was es gibt; ohne Kader auf beiden Seiten bleibt von ihr "return true" uebrig. Sonst haette eine Forderung nach Namen, die niemand erfuellen kann, das Melden verhindert statt es zu ordnen. Gemessen an drei Faellen: beide Kader (12 Felder je Seite), nur der Heimkader (12 zu 0, und die Pruefung liest nur heim), keiner (0 Felder, Pruefung ohne Feldzugriff, ein 5:3 speichert mit vier Spieler-IDs 0 und Begegnungsstand 5:3 bei Spielpunkten 1:0) — der letzte Fall ausdruecklich mit "Spielernamen: Pflicht". Nebenbei behoben: - Durchweg leere Satzfelder gewannen gegen ein vorhandenes Summenergebnis; das blosse Oeffnen und Speichern loeschte damit Altbestand (gemessen: von sieben gespeicherten Spielen blieb eines uebrig). - "Doppel separat" wurde allein aus punkte_sieg_* abgeleitet; abweichende Doppelwerte in den neuen Feldern waeren verborgen und beim naechsten Speichern ueberschrieben worden. - Zwei hartkodierte deutsche Zeichenketten im uebersetzten Formular nutzen jetzt ihre vorhandenen Sprachschluessel. - COM_SPORTSMANAGER_SETS fuehrte den Umlaut als HTML-Entitaet und wurde in zwei Auswahlfeldern erneut maskiert ("Sätze"); jetzt literal.	2026-09-06 21:23:49 +02:00
svennickel	f787681fec	fix: compare goals numerically in spielpunkte_bedingung() ... Refs #294	2026-08-24 23:10:16 +02:00