mirror of
https://github.com/Deutscher-Tischfussballbund/com_sportsmanager.git
synced 2026-09-11 18:41:50 +00:00
7b8fbe6f4555b097f6c5152b3d25977de5b25875
18
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 svennickel
|
7b8fbe6f45 |
Ein 5:5 ist eingetragen: das Signal "Ergebnis liegt vor" vom Punktestand loesen
Meldung von Sven (DTFB-IT): "Ist irgendwo zwischendurch ein 5:5 werden alle
Ergebnisse und Paarungen beim Speichern ab dort geloescht." Seine Vermutung
traf zu: teamspiel_*_punkte zaehlt nur ENTSCHIEDENE Saetze, und punkte == 0:0
gilt an mehreren Stellen als "nichts eingetragen". Wo Unentschieden normal
sind (Je-Satz-Modus, Satzergebnis-Erfassung), kollidiert das.
Gemessen an PRUEF Liga G (Modus 21, je Satz): eingetragen Spiel 1
"6:4 5:5 2:6 6:3", Spiel 2 "5:5 5:5", Spiel 3 "4:4 6:2 5:5 2:6" -- gespeichert
wurde nur Spiel 1. Spiel 2 ergibt Punkte 0:0, damit war die Behalte-Bedingung
(admin.php) und die do-while-Bedingung falsch, die Schleife endete, und
DELETE ... WHERE teamspiel_nummer >= $spiel_nr nahm Spiel 2 UND Spiel 3 mit.
Die falschen Gesamttore aus der Meldung sind eine Folge derselben Loeschung;
ohne komplett unentschiedenes Spiel stimmen sie exakt (47:42 = Handrechnung).
Ausserdem gemessen: eine Begegnung, deren Spiele ALLE unentschieden enden
(Begegnungspunkte 0:0), verschwand komplett aus der Tabelle -- die Mannschaft
zeigte danach "0 Siege, 0 Unentschieden, 1 Niederlage", Spielpunkte und Tore
der Begegnung fehlten. Grund: die Tabellenabfragen filtern Begegnungen mit
(heim_punkte != 0 OR gast_punkte != 0).
Behebung: ueberall dort, wo punkte != 0 als "es liegt ein Ergebnis vor"
dient, gilt zusaetzlich "ein Satzergebnis liegt vor" -- das Kriterium wird
erweitert, nie verengt:
- Speicherschleife adminSaveBegegnungSpielplan(): Behalte-Bedingung und
do-while zusaetzlich !empty($ergebnis_detailliert). Auf teamspiel-Ebene ist
ergebnis_detailliert das unmittelbare Zeugnis der Eingabe; es ist genau dann
gefuellt, wenn Satzergebnisse eingetragen wurden.
- Wiederherstellungs-Block fuer Zwischenergebnisse: Punkte werden nur noch
zurueckgeholt, wenn NEBEN 0:0 auch kein Satzergebnis gesendet wurde -- ein
live eingetragenes "5:5 5:5" ist eine Eingabe, keine Luecke.
- Tabellenabfragen (getTabelleSpieltag, teamstatistikAktualisieren samt
Buchholz-Paarungen): ausgetragen ist eine Begegnung mit punkte != 0 ODER
heim_tore IS NOT NULL. Auf Begegnungsebene gibt es kein ergebnis_detailliert;
heim_tore (Datenbankversion 123) wird beim Speichern genau dann gesetzt, wenn
Satzergebnisse vorliegen, und ist damit dort das eindeutige Signal.
- Spieltag-Ermittlung (tabelle(), teamstatistikAktualisieren): ein Spieltag
mit heim_spielpunkte 0:0 (Wertung "je Satz, Sieg 1": alle Spiele remis)
zaehlt ueber NOT ISNULL(heim_tore) trotzdem als ausgetragen.
Bestandsmodi aendern sich nicht: ausserhalb der Satzergebnis-Erfassung ist
bei "nicht eingetragen" auch kein Satzergebnis vorhanden (ergebnis_detailliert
leer, heim_tore NULL), das erweiterte Kriterium bleibt dort wirkungslos. Die
SQL-Zusaetze sind an $je_satz gebunden bzw. haengen an Spalten, die in
Bestandsdaten NULL sind; die von getTabelleSpieltag erzeugten Abfragen bleiben
fuer Nicht-Je-Satz-Modi byteidentisch (Query-Log-Vergleich wie bei
|
||
|
svennickel
|
cc07d7d53a |
Kein Satzstand je Spiel, wo je Satz gewertet wird
Sven 2026-09-09 mit Bildschirmfoto des Begegnungsformulars: „Bei dem Modus ‚für
jeden Satz einzeln' erscheint mir die Anzeige der Satzergebnisse bei den Spielen
nicht sinnvoll beim Bearbeiten der Begegnung. Zeige diese da nicht an."
Zu Recht: die Zeile „Saetze: 2:1" unter einem Spiel beantwortet dort eine Frage,
die in diesem Modus niemand stellt. Gewertet wird jeder Satz einzeln — der
Satzstand des Spiels entscheidet nichts mehr, und daneben steht bereits der
Gesamtstand, der die tatsaechlich vergebenen Spielpunkte zeigt.
Die Zeile entfaellt deshalb je Spiel, dessen Wertung „je Satz" ist (Einzel und
Doppel getrennt betrachtet, weil beide eine eigene Wertung haben koennen).
Die beiden VERBORGENEN Felder darunter bleiben in jedem Fall stehen: sie tragen
`spiel_N_heim_punkte`/`_gast_punkte` zum Server, und das Satz-JavaScript
beschreibt sie weiter. Nur die sichtbare Zeile faellt weg; das JS, das sie
fuellt, prueft ohnehin auf Vorhandensein (`if (anzeige != null)`) und laeuft
unveraendert.
Gemessen am Testserver:
Liga G (je Satz): 0 Satzstand-Anzeigen, 6 verborgene Punktefelder
Liga F (Satzdetail, aber
Wertung je Spiel): 3 Anzeigen, 3 span-Elemente, 6 Punktefelder
|
||
|
svennickel
|
1a111b792f |
Je Satz in allen drei Punkteskalen, systematisch kodiert
Sven 2026-09-09: „Bei ‚Spielpunkt' ‚Für jeden Satz einzeln': hier wuerde ich
analog zu den Auswahlen oben ergaenzend noch ‚Sieg: 1 Punkt' und ‚Sieg: 3 Punkte,
Unentschieden: 1 Punkt' noch mit vorsehen wollen in geeigneter Reihenfolge." Und:
„solange es kompatibel zu dem Stand vor #304/#306 ist" — der Wert des Modus war
also frei gestaltbar.
Statt weitere Einzelwerte anzuhaengen (4, dann 5, dann 6) traegt der Wert die
Bedeutung jetzt selbst:
Wert % 10 = die Punkteskala (0 = Sieg 2/Remis 1, 1 = Sieg 3/Remis 1,
2 = ohne Umrechnung, 3 = Sieg 1)
Wert >= 10 = je SATZ statt je Spiel
je Spiel: 3 0 1 2 je Satz: 13 10 11
^^ ^^ ^^ dieselbe Skala, +10
Die ueberlieferten Werte 0 bis 3 behalten damit ihre Bedeutung unveraendert —
das ist die geforderte Kompatibilitaet zum Stand vor #304. Und jede der drei
Rechenstellen leitet Siegwert und Remiswert aus demselben Grundwert ab, statt
einen Sonderfall je Wert zu fuehren: aus einer Fallunterscheidung mit vier
Zweigen wurden zwei Zeilen.
Der Entwicklungswert 4 (nur in #306, nie ausgeliefert) entfaellt ersatzlos; er
existierte allein auf dem Testserver und ist dort auf 10 gesetzt. Deshalb auch
keine Migration dafuer — in keiner Installation steht er.
Der Server nimmt nur noch die sieben gueltigen Werte an; alles andere faellt auf
0 zurueck. Fehlt die Satzerfassung, faellt eine Je-Satz-Wertung auf IHRE EIGENE
Skala je Spiel zurueck (13 -> 3, nicht mehr pauschal auf 0): die gewaehlte
Punkteskala ist eine andere Aussage als die Bezugsebene und bleibt erhalten.
VERIFIZIERT, alles gemessen statt angenommen:
1. Bestand unveraendert: Ausgangsstand gesichert, alle sieben Pruefmodi ueber die
echten Formulare neu gespeichert, 784-Zeilen-Dump aller wertungsrelevanten
Tabellen — IDENTISCH. Am Ende, nach dem Durchlauf aller drei neuen Skalen und
Ruecksetzen auf 10, erneut identisch.
2. Spielpunkte je Skala gegen eine UNABHAENGIGE Nachrechnung in Python (parst
ergebnis_detailliert selbst, kein PHP beteiligt): 8 Spiele + 3 Begegnungen,
je Skala 0 Abweichungen. Darunter der Faelligkeitsfall, dass „Sieg 1 Punkt"
fuer Unentschieden NICHTS gibt (Spiel mit 1 Sieg, 1 Niederlage, 2 Remis:
1:1 statt 2:2) und der Rueckfall ohne Satzdetails (Skala x Satzsiege).
3. Spielerstatistik je Skala gegen dieselbe Art Nachrechnung: 7 Spieler, je
Skala 0 Abweichungen. Siege/Unentschieden/Niederlagen sind ueber alle Skalen
gleich (die Skala aendert nur Spielpunkte, nicht wer einen Satz gewann), die
Spielpunkte skalieren mit 1/2/3.
4. Das erzeugte JavaScript traegt je Skala die passenden Faktoren
(1*/0*, 2*/1*, 3*/1*) — aus der gerenderten Seite gelesen.
5. Die Auswahl zeigt drei Je-Satz-Eintraege in derselben Reihenfolge wie oben
(Sieg 1, Sieg 2/Remis 1, Sieg 3/Remis 1); ohne Satzerfassung bleibt die ganze
Gruppe verborgen.
Der Warnhinweis spricht nicht mehr von „2 Punkten je gewonnenem Satz", sondern
vom vollen Siegwert — mit drei Skalen waere die Zahl falsch gewesen.
|
||
|
svennickel
|
fa63e1e2d6 |
Spielpunkte-Auswahl gruppieren, und die Hinweise brechen wieder um
Sven 2026-09-09 mit zwei Bildschirmfotos: „Benenne die Optionen geeignet,
geeignet angeordnet und gut unterscheidbar." Und: „Und brich die Beschreibungen
geeignet um."
1. DIE BESCHREIBUNGEN — ein Schaden, den
|
||
|
svennickel
|
111fdeb306 |
Spielerstatistik im Je-Satz-Modus: jeder Satz zaehlt wie ein Spiel
Der STFV will in der Spielerstatistik jeden Satz als Spiel gezaehlt sehen. spielerstatistikAktualisieren() holt dafuer im Veranstaltungs-Zweig zusaetzlich ergebnis_detailliert und die beiden Wertungs-Spalten (der Join auf teamspiel_modus existiert schon), bestimmt je Zeile Einzel oder Doppel wie begegnungenAktualisieren ueber ISNULL(spieler_2_id) und zaehlt bei Wertung 4 Siege/Unentschieden/Niederlagen und die Satz-Spalten je SATZ aus runden_detailliert_auswertung — die angezeigte Spielezahl ist s+u+n und wird damit von selbst zur Satzzahl. spg/spv bleiben die (im 4er-Modus bereits satzbasierten) Spielpunkte; pg/pv bleiben die Punktesummen, also Saetze — ihre Einheiten-Beschriftung haengt an punktetyp und bliebe bei einer Tore-Umwidmung falsch. Ohne gespeicherte Satzergebnisse (App-Meldung nur mit Satzstand) zaehlt das Spiel wie bisher als EIN Spiel aus dem Punktevergleich — deterministisch, keine erfundenen Saetze. Die S/U/N-Zaehlung und die Satz-Spalten laufen jetzt ueber dieselben drei Zaehler (heim/unentschieden/gast je Zeile): fuer jede Wertung ausser 4 tragen sie exakt die alten 1-aus-3-Werte, das Ergebnis ist wertgleich zum bisherigen if/else — bewiesen ueber die Messlatte, nicht nur hergeleitet: 11 Modi + 11 Begegnungen unveraendert gespeichert, voller Datenbank-Dump (784 Zeilen) und Frontend-Dump (26987 Zeilen) vor/nach dem Wechsel — die EINZIGEN Unterschiede sind die 7 bestenliste_punkte-Zeilen der Je-Satz-Prueflige G, und dort nur s/u/n und sg/su/sv; spg/spv und pg/pv jeder Zeile sind unveraendert. Alle sieben Bestands-Bestenlisten (einschliesslich der Liga 'Mehrere mit Ergebnis je Satz' bei Wertung Sieg 2/Remis 1, die weiter je SPIEL zaehlt) sind identisch. Handrechnung dokumentiert an Spieler 115 der Prueflige G: Einzel '6:4 4:4 2:6 6:3' (2/1/1), Doppel '4:4 4:4 6:2 2:6' (1/2/1), Doppel '6:4 6:4 0:6 4:6' als Gast (2/0/2), dazu die Fallback-Begegnung ohne Satzdetails als eine Niederlage (0/0/1): zusammen 5 Siege, 3 Unentschieden, 5 Niederlagen = 13 'Spiele' (Saetze), Spielpunkte 15:15, Punkte 6:6 — exakt die gespeicherte Zeile. |
||
|
svennickel
|
49ce079900 |
Tabellensortierung im Je-Satz-Modus: Begegnungspunkte, Spielpunkte, TORE
Im Je-Satz-Modus ist die Satzdifferenz nach der Spielpunkte-Differenz vollstaendig redundant (Spielpunkte-Differenz = 2 x Satzdifferenz) — die naechste Stufe, die wirklich trennt, sind die Tore (#306-Konzept, Abschnitt 0 und 3). Die Sortierung haengt am MODUS, nicht an neuen tabellenwertung- Werten: so wirkt die Tore-Stufe automatisch in Differenz-, Quotienten-, Buchholz- und Direktvergleichs-Varianten, ohne die Auswahlliste zu verdoppeln. getTabelleSpieltag(), teamstatistikAktualisieren() und getTabelleDirekterVergleich() ermitteln die Wertung des Modus jeweils per eigenem kleinen SELECT und schieben bei Wertung 4 die Stufe tore_differenz DESC (bzw. tore_quotient) ZWISCHEN Spielpunkte und Punkte; die Satz-Stufe bleibt als letzter Tie-Break dahinter — sie schadet nie, und solange Tore noch NULL sind, ordnet die Tabelle exakt wie bisher. Die Summen entstehen als SUM ueber CASE je Begegnung ohne COALESCE: NULL traegt nichts bei, unbekannt wird niemals 0:0. Die Platzvergabe (geteilte Plaetze) beachtet die Tore an beiden Stellen (teamstatistik und HTML-Tabelle) mit — ohne das teilten sich zwei nur durch Tore getrennte Teams Platz 1, gemessen am Zwischenstand dieses Schrittes. Die HTML-Tabelle zeigt die neue Stufe: im Je-Satz-Modus steht zwischen der Saetze- und der Spiele-Spalte eine Tore-Spalte (Differenz bzw. Quotient, absolut als Tooltip/Beiwert, "-" wo Tore unbekannt sind). Die JSON-Ansicht bekommt die tore_*-Felder additiv ueber die ohnehin rohen Team-Zeilen. Fuer alle anderen Modi entsteht BYTEIDENTISCHES SQL — nicht behauptet, sondern geloggt: beide Fassungen im Testserver mit einem Query-Log instrumentiert, 18 getTabelleSpieltag-Aufrufe (9 Ligen x 2 Spieltage) und 19 teamstatistik-Laeufe verglichen. Saemtliche Unterschiede betreffen ausschliesslich die Je-Satz-Liga (2 Zusatzspalten, 2 Subselects, eine ORDER-Stufe); jede Query einer Nicht-4-Liga ist Byte fuer Byte gleich. Dazu dieselbe Messlatte wie bisher: 11 Modi + 11 Begegnungen unveraendert gespeichert, Datenbank-Dump (778 Zeilen): 0 Unterschiede; Frontend-Dump (9 Ligen x 3 Ansichten + 8 Statistiken): jede Abweichung ist eine HINZUGEKOMMENE Zeile der Tore-Spalte der Je-Satz-Liga, keine einzige bestehende Zeile geaendert oder entfernt. Und der Fall, fuer den die Stufe da ist, ist konstruiert und gemessen (Prueflige H): eine Remis-Begegnung, beide Teams mit Begegnungspunkten 1, Spielpunkte-Differenz 0 und Satz-Differenz 0, aber Toren 35:34 gegen 34:35. Alte Kette: beide Platz 1, alphabetisch sortiert (Adler vor Zebras). Neue Kette: Zebras (+1 Tore) Platz 1, Adler (-1) Platz 2 — in team.platz wie in der angezeigten Tabelle. |
||
|
svennickel
|
64588f71ac |
Wertung 4: Sieg 2 / Unentschieden 1 — je SATZ (der STFV-Modus)
Der STFV wertet jeden gewonnenen Satz mit 2 Spielpunkten und jedes
Satz-Unentschieden mit 1 Punkt je Seite. Das ist ein neuer Wert der
bestehenden Stellschraube spielpunkte_wertung_* (tinyint, Wert 4), keine
neue Spalte und keine Kombinatorik (#306-Konzept, Abschnitt 1). Nach aussen
bleibt der Modus punktetyp 1 + satzergebnisse 1 — die Punkte eines Spiels
SIND weiter die gewonnenen Saetze, punktetyp behaelt seine zwei Werte.
Die Regel sitzt in spielpunkteFuerSpiel(): 2·gewonnene + 1·unentschiedene
Saetze je Seite aus ergebnis_detailliert; ohne Detail (App-Meldung nur mit
Satzstand) deterministisch 2·punkte — Satzsiege sind bekannt, Remis nicht.
Beide PHP-Rechenwege bekommen dadurch denselben neuen Fall geschenkt.
Das Formular bietet die Option nur an, wo sie rechenbar ist: sichtbar
allein bei "Mehrere - mit Ergebnis je Satz" (data-satzdetails-Option,
zeilen_anzeigen() blendet sie sonst aus und stellt die Auswahl zurueck).
Der Server verlaesst sich darauf nicht: kommt Wertung 4 ohne punktetyp 1 +
satzergebnisse 1 an, faellt sie auf 0 zurueck (Sieg 2/Remis 1 je Spiel, die
naechstliegende Je-Spiel-Regel) — die Spielform dominiert, wie im
Bestandscode. Race schliesst 4 automatisch aus, weil Race Wertung 2
erzwingt. Gemessen an drei ueber das echte Formular geposteten Modi:
Einer+4 -> 0, Mehrere-ohne-Satzerfassung+4 -> 0, Race+4 -> 2. Und der
Warnhinweis beim Speichern mit Bestandsergebnissen nennt jetzt auch den
STFV-Altbestandsfall: wo unter "Mehrere" in Wahrheit Tore in den
Punkte-Feldern stehen, zaehlt nach dem Wechsel jedes Tor wie ein gewonnener
Satz doppelt — umgerechnet wird nichts.
Die DRITTE Rechenstelle rechnet mit — die Lehre aus dem Remis-Vorfall
(Formular 7:3, Server 6:2): das erzeugte Formular-JavaScript bekommt EINE
gemeinsame Satzsummen-Hilfsfunktion (satz_summen liest die
_punkte_detailliert-Felder und ueberspringt 0:0-Saetze wie die
Satz-Zaehlschleife des Servers), und BEIDE Verbraucher benutzen sie:
gesamtstand_aktualisieren() und spielpunkte_bedingung(). Aus den
spiel_N_*_punkte-Feldern duerfen beide im 4er-Modus nicht mehr rechnen —
dort stehen Saetze, eine Je-Spiel-Wertung waere falsch.
End-to-end gemessen an der neuen Prueflige G (Modus ueber das echte
Formular angelegt: 3 Spiele E/E/D, 4 feste Saetze, Wertung je Satz;
punkte_sieg wird -3 gespiegelt):
- Begegnung 117 mit Satz-Remis in allen drei Spielen ("6:4 4:4 2:6 6:3",
"1:6 2:6 6:6 0:6", "4:4 4:4 6:2 2:6"): gespeichert 5:3, 1:7, 4:4 —
Begegnung 10:14 Spielpunkte, 3:5 Saetze, 43:57 Tore. Handrechnung
identisch.
- JS-Paritaet nicht nur gelesen, sondern gerechnet: das vom PHP erzeugte
JavaScript aus der gerenderten Seite in node gegen dieselben Feldwerte
laufen lassen — gesamtstand_aktualisieren liefert 10:14,
spielpunkte_bedingung summiert 10/14, satz_summen je Spiel
[2,1,1] [0,1,3] [1,2,1]; die Datenbank derselben Begegnung sagt 10:14.
- Fallback gemessen (Begegnung 119, Meldung wie ein Altclient nur mit
Satzstand 2:1 und 1:1): Spielpunkte 4:2 und 2:2 (= 2·punkte),
ergebnis_detailliert bleibt leer, Tore bleiben NULL.
- Bestandsmodi unveraendert: dieselbe Messlatte wie bei den beiden
Schritten zuvor (10 Modi + 10 Begegnungen unveraendert gespeichert,
756 Zeilen Datenbank-Dump, 30995 Zeilen Frontend-HTML): VOLLSTAENDIG
identisch.
Neue Sprachschluessel DE/EN: die Option ("Sieg: 2 Punkte, Unentschieden:
1 Punkt - je Satz") und der erweiterte Warnhinweis.
|
||
|
svennickel
|
79f3abc01a |
Torsummen als eigene Spalten, NULL heisst unbekannt (Datenbankversion 123)
Die STFV-Tabellensortierung braucht als letzte inhaltliche Stufe die Tore — und
die stehen bisher ausschliesslich im tinytext ergebnis_detailliert, wo kein SQL
sie lesen kann (#306-Konzept, Abschnitt 2). Also neue, durchweg NULL-bare
Spalten: teamspiel_heim_tore/gast_tore, begegnung.heim_tore/gast_tore und
team.tore_gewonnen/verloren/differenz/quotient (Typen nach punkte_*-Vorbild).
toreFuerSpiel() in tools.php ist die einzige Rechenstelle: bei punktetyp 0 sind
die Punkte die Tore; wo Satzergebnisse gefuehrt werden (satzergebnisse 1),
werden sie aus ergebnis_detailliert summiert (runden_detailliert_auswertung);
sonst NULL — unter "Mehrere" ohne Satzerfassung spiegelt das Detail nur den
Satzstand, eine Torzahl steht dort nicht und stand dort nie. Geschrieben wird
an denselben zwei Stellen wie die Spielpunkte (Spielbericht speichern und
begegnungenAktualisieren), immer paarweise gesetzt oder paarweise NULL; das
Loeschen des Spielberichts nullt die Begegnungssummen mit. team.tore_* rechnet
teamstatistikAktualisieren immer mit — als SUM ueber CASE je Begegnung, OHNE
COALESCE: eine Begegnung mit unbekannten Toren traegt nichts bei, unbekannt
wird niemals als 0:0 gewertet. Gemessen an Prueflige F: ein geleertes
ergebnis_detailliert macht Spiel, Begegnung und die Differenz beider Teams
NULL (135/147 -> 85/98), die Wiederherstellung stellt exakt den alten Stand her.
KEIN Backfill in der Migration: updateDatabase() ruft begegnungenAktualisieren()
nicht auf, und ein Update soll gespeicherte Werte nicht anfassen. Gemessen: nach
Einspielen und einem Seitenaufruf steht die Version auf 123, alle 455 + 116 + 32
Tore-Felder sind NULL. Befuellt wird beim naechsten Speichern eines Berichts
bzw. komplett beim Speichern des Modus — gemessen ueber alle acht Ligen:
Einer/Race tragen Tore = Punkte (Damenbundesliga 42:31 -> 42:31), Satzerfassung
summiert die Saetze ("5:3 4:4 2:6 6:1" -> 17:14, Begegnung 50:49), "Mehrere"
ohne Satzerfassung bleibt ehrlich NULL (PRUEF Liga A, 30 Spiele, 0 Tore-Werte).
Beide Pflegeorte: Migration <123 in database/update.php (getTableColumns-Guard
je Tabelle, Versionsschreiben am Ende) UND die CREATEs in script.php samt
datenbank_version 123. Gemessen per probe_-Tabellen aus den Neuinstallations-
CREATEs gegen die migrierten Tabellen (information_schema: Name, Position, Typ,
Nullable, Default): alle drei Tabellen spaltenidentisch.
Bestand unberuehrt, gemessen mit derselben Messlatte wie beim Refactoring:
alle zehn Modi und dieselben zehn Begegnungen unveraendert erneut gespeichert,
danach Datenbank-Dump der Bestandsspalten (756 Zeilen) und Frontend-Dump
(30995 Zeilen HTML) gegen den Lauf mit dem alten Code verglichen:
VOLLSTAENDIG identisch.
|
||
|
svennickel
|
e1a0637795 |
Spielpunkte-Regel an eine Stelle: spielpunkteFuerSpiel() in tools.php
Vorarbeit fuer die STFV-Satzwertung (#304/#306-Konzept, Abschnitt 6): die Spielpunkte-Kaskade stand woertlich doppelt im PHP — einmal beim Speichern des Spielberichts (admin.php, Rechenweg A), einmal in begegnungenAktualisieren() (sportsmanager.php, Rechenweg B). Der Remis-Vorfall ( |
||
|
svennickel
|
5d1df8579d |
Gleicher Satzstand bleibt ein Unentschieden — die Sonderregel kommt weg
Sven beim Testen von Begegnung 93 (2:2 im Doppel, Modus 3 Gewinnsaetze,
Wertung Sieg 2/Remis 1): das Formular rechnete 7:3 vor, gespeichert wurde 6:2.
„Und das ist meinem Verstaendnis nach doch auch das richtige Ergebnis?" — ja.
Zwei Fehler in einem:
1. Die Spielpunkte werden an DREI Stellen berechnet, nicht an zweien: zusaetzlich
zu admin.php und begegnungenAktualisieren() rechnet das Formular selbst per
JavaScript mit (view_admin.php, spielpunkte_bedingung()). 554ad25/35384a5
hatten die Remis-Sonderregel in die ersten beiden eingebaut, die dritte lief
nach der alten Regel weiter — daher 7:3 gegen 6:2.
2. Die Sonderregel selbst war falsch. „Unentschieden nur, wo der Satzmodus es
zulaesst" war eine Ableitung aus
|
||
|
svennickel
|
7f1bedc41e |
Kommentare aus dem Quelltext entfernen
Aus dem Review: „Der Quelltext ist absolut ueberkommentiert." Nach dem Kuerzen in |
||
|
svennickel
|
35384a5c43 |
Die Remis-Regel galt nur auf einem der beiden Rechenwege
Sven 2026-09-08: „Teste fuer alle Modus, ob Siege, Unentschieden und
Niederlagen weiter korrekt berechnet werden pro Spiel fuer saemtliche
Modusszenarien."
Beim Testen ueber die volle Matrix (4 Spielpunkte-Wertungen x 7 Satzmodi x 4
Spielstaende = 112 Szenarien) kam ein Fehler DIESES Zweigs heraus: die
Spielpunkte werden an ZWEI Stellen berechnet, und 09ae1c1/554ad25 hatte die
Remis-Pruefung nur in eine davon eingebaut.
Weg A admin.php, Spielbericht speichern — MIT Pruefung
Weg B sportsmanager.php, begegnungenAktualisieren() bei Modus-/
Wettbewerbsaenderung — OHNE Pruefung
Dasselbe Spiel bekam damit verschiedene Spielpunkte, je nachdem, welcher Weg es
zuletzt angefasst hatte: Speichern ergab 0:0, ein Moduswechsel schrieb 1:1
zurueck. Betroffen sind Gleichstaende ungleich 0:0 in Wettbewerben, deren
Satzmodus kein Remis zulaesst (ein fester Satz, ungerade Satzzahl,
Gewinnsaetze) bei Wertung „Sieg 2/Remis 1" oder „Sieg 3/Remis 1" — 8 der 112
Szenarien. Gemessen, nicht geschaetzt.
Die Regel steht jetzt als remisMoeglich() auf Dateiebene und wird von beiden
Wegen aufgerufen, statt als Closure in einem der beiden Loops zu leben.
Matrix danach: 0 Widersprueche.
NICHT betroffen und mitgeprueft:
- Siege/Unentschieden/Niederlagen je Spiel sind in ALLEN 112 Szenarien
unveraendert. Sie kommen in der Spielerstatistik aus dem Vergleich der
PUNKTE (sportsmanager.php:6338), nicht aus den Spielpunkten, und an den
Punkten aendert dieser Zweig nichts.
- Race bleibt unberuehrt: die Race-Normalisierung setzt die Wertung auf 2
(„ohne Umrechnung"), und dort gibt es keinen Remis-Zweig.
- spielerstatistikAktualisieren() selbst ist unveraendert (nur die
Einheiten-Beschriftung kam hinzu).
|
||
|
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. |
||
|
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. |
||
|
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). |
||
|
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. |
||
|
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&auml;tze"); jetzt literal.
|
||
|
svennickel
|
f787681fec |
fix: compare goals numerically in spielpunkte_bedingung()
Refs #294 |