Gefunden beim Umsetzen von D-108 (Paket 21.1b, PR folgt). Der Worker hat gemeldet, dass eine erwartete Hash-Bewegung ausblieb, und nachgesehen warum.
Befund
MatchFingerprint.ComputeRulesHash64 baut die Regelidentität ausschliesslich aus numerischen Regelkonstanten — darunter BuildInfluenceRadiusCells. Die Ankerrollenliste war nie ein gehashtes Feld.
Folge: D-108 ändert das Bauverhalten spürbar (statt HQ/Lager/Kraftwerk wird jedes fertige Gebäude zum Anker), und RulesHash64 bleibt trotzdem unverändert. Zwei Builds diesseits und jenseits dieser Änderung melden dieselbe Regelidentität, spielen aber verschiedene Regeln.
Genau das ist der Zustand, gegen den der Hash existiert.
Wie schlimm ist das heute
Praktisch abgefedert, konzeptionell offen. Die Lobby sendet seit D-092/D-094 den Build-Commit (BuildInfo.Commit) beim Erstellen und Beitreten mit, und der Server weist Paare mit unterschiedlichen Builds ohnehin ab. Ein Desync durch genau diese Lücke setzt also voraus, dass jemand den Commit-Abgleich umgeht. Für den anstehenden Betatest ist das kein Blocker.
Konzeptionell bleibt es ein Loch: der Hash verspricht "gleiche Regeln", hält es aber nur für die Regeln, die zufällig als Zahl vorliegen. Die nächste Regeländerung, die keine Konstante bewegt, fällt genauso durch.
Was zu tun wäre
Eine RulesRevisionV4 mit einem zusätzlichen Feld, das die Ankerregel abbildet — und grundsätzlicher die Frage, ob der Hash künftig auch nicht-numerische Regelentscheidungen tragen soll.
Das geht nicht nebenbei. Scripts/Simulation/Replays/ ist im Parallelbetrieb als niemand ohne D-ID geführt: Speicherformat und Fingerprint zu ändern ist eine Inhaberentscheidung. Deshalb dieses Issue statt eines PR.
Abgrenzung
D-108 wird nicht dadurch aufgehalten. Die Regeländerung ist fertig, 726/726 grün, ohne Baseline-Bewegung. Dieses Issue hält nur fest, dass die ausgebliebene Hash-Bewegung kein Glück war, sondern eine Lücke.
Gefunden beim Umsetzen von D-108 (Paket 21.1b, PR folgt). Der Worker hat gemeldet, dass eine erwartete Hash-Bewegung ausblieb, und nachgesehen warum.
Befund
MatchFingerprint.ComputeRulesHash64baut die Regelidentität ausschliesslich aus numerischen Regelkonstanten — darunterBuildInfluenceRadiusCells. Die Ankerrollenliste war nie ein gehashtes Feld.Folge: D-108 ändert das Bauverhalten spürbar (statt HQ/Lager/Kraftwerk wird jedes fertige Gebäude zum Anker), und
RulesHash64bleibt trotzdem unverändert. Zwei Builds diesseits und jenseits dieser Änderung melden dieselbe Regelidentität, spielen aber verschiedene Regeln.Genau das ist der Zustand, gegen den der Hash existiert.
Wie schlimm ist das heute
Praktisch abgefedert, konzeptionell offen. Die Lobby sendet seit D-092/D-094 den Build-Commit (
BuildInfo.Commit) beim Erstellen und Beitreten mit, und der Server weist Paare mit unterschiedlichen Builds ohnehin ab. Ein Desync durch genau diese Lücke setzt also voraus, dass jemand den Commit-Abgleich umgeht. Für den anstehenden Betatest ist das kein Blocker.Konzeptionell bleibt es ein Loch: der Hash verspricht "gleiche Regeln", hält es aber nur für die Regeln, die zufällig als Zahl vorliegen. Die nächste Regeländerung, die keine Konstante bewegt, fällt genauso durch.
Was zu tun wäre
Eine
RulesRevisionV4mit einem zusätzlichen Feld, das die Ankerregel abbildet — und grundsätzlicher die Frage, ob der Hash künftig auch nicht-numerische Regelentscheidungen tragen soll.Das geht nicht nebenbei.
Scripts/Simulation/Replays/ist im Parallelbetrieb alsniemand ohne D-IDgeführt: Speicherformat und Fingerprint zu ändern ist eine Inhaberentscheidung. Deshalb dieses Issue statt eines PR.Abgrenzung
D-108 wird nicht dadurch aufgehalten. Die Regeländerung ist fertig, 726/726 grün, ohne Baseline-Bewegung. Dieses Issue hält nur fest, dass die ausgebliebene Hash-Bewegung kein Glück war, sondern eine Lücke.