Berlin Drift offline practice
0 fps 0 km/h N 800 rpm 0 drift 100 boost 1/3 P1
--navigation
--direction
00:00timer
stay on roadcondition
--
Prenzlauer Berg

Vollbildkarte

M / Select: öffnen oder schließen · Pfeiltasten: Karten-Cursor bewegen · Enter oder Leertaste: Wegpunkt setzen/verschieben · Entf/Backspace: löschen · Karte antippen: Wegpunkt setzen · Esc: schließen

Player Waypoint
Release notes

Berlin Drift changelog

v2026-07-25-142259 Prepared · Unreleased

Technische Zusammenfassung

Der immutable Candidate-Release 2026-07-25-142259 enthält transparent das vollständige tatsächliche Delta seit dem produktiven Release 2026-07-23-205700. Er ist prepared und unreleased, weder deployed noch current; für diesen Candidate existiert kein produktives Image-Digest. 2026-07-23-205700 bleibt der einzige current/deployed Release, der unmittelbar produktive Vorgänger und die rollbackfähige Produktionsbasis. Issue #23 von Milone bleibt offen; dieser Candidate behauptet weder Rollout noch fachliche Abnahme.

  • Bedienbarer Changelog-Dialog: Der Versionsschalter öffnet einen nativen modalen Dialog mit eigenständigem Schließen-Button (type="button"). Aktivierung des X, Klick auf den Backdrop und das native cancel-Ereignis der Escape-Taste führen über denselben Controllerpfad; die Escape-Behandlung verhindert die Browser-Standardaktion und schließt kontrolliert.
  • Begrenztes Scrollen: Der Dialog verwendet ein zweizeiliges Grid mit minmax(0, 1fr), dynamischer Viewport-Höhe und einer fokussierbaren Scrollregion. overflow-y: auto, overscroll-behavior: contain, touch-action: pan-y und scrollbar-gutter: stable halten lange Release Notes per Tastatur, Touch und Zeigegerät erreichbar, ohne dass der Dialog über den Viewport wächst.
  • Transaktionaler Dialog-, Pause- und Fokus-Lifecycle: Öffnen übernimmt Pause-, Input-, inert-, Pointer- und Fokusbesitz atomar. Schließen oder ein Fehler stellt den vorherigen Zustand wieder her; bleibt ein teilweise geöffneter Dialog wegen eines fehlerwerfenden close() sichtbar, bleiben Gameplay, Pause und Hintergrund fail-closed gesperrt, bis ein späterer Close-Versuch die Wiederherstellung abschließt.
  • Zentraler fail-closed Input-Lifecycle: Tastatur- und Gamepadzustand werden durch eine autoritative Lifecycle-Komponente statt durch verteilte Sets und Latches verwaltet. Referenzgezählte Suppression-Tokens für Changelog, Fenster-Blur und Dokument-Sichtbarkeit löschen aktive Eingaben; während einer Sperre gehaltene Tasten bleiben bis zu ihrem echten keyup blockiert und können nach der Freigabe nicht als stale Eingabe wiedererscheinen.
  • Gamepad-Snapshot, Ownership und Edge-Synchronisation: Browser-Snapshots werden begrenzt, normalisiert und als unveränderliche Kopien konsumiert. Auswahl, Connection-Epoch und Generation verhindern Identitätsverwechslungen bei Disconnect/Reconnect; Pause-, Kamera- und Kartenaktionen entstehen nur an frischen Press-Edges. Öffnen/Schließen, Host-Fehler, ungültige Snapshots und Controllerwechsel synchronisieren Latches, sodass kein Buttonzustand verspätet abgespielt wird.
  • Importierbare Produktionskomposition: createGameplayInputBootstrap verbindet DOM-Events, Frame-Polling, Keyboard-/Gamepad-Updates und Changelog-Transaktionen an einer getesteten Grenze. Fehlerwerfende Browserzugriffe, ungültige Suppression-Tokens und fehlgeschlagene Zustandswiederherstellung bleiben fail-closed, während bestehende Startmenü-, Vollbildkarten-, Pause- und Kamera-Gates erhalten bleiben.
  • Regressionen und Scope: Node-Tests prüfen Dialog-X, Backdrop, Escape, Scrollvertrag, atomare Rollbacks, mehrfache Suppressionsgründe, Blur/Visibility, Held-Key-Replay, Gamepad-Ownership, Snapshot-Faults und Produktionskomposition. Python- und Node-Beziehungstests leiten Candidate und Current generisch aus Runtime und Rollen ab. Issue #23 bleibt bis zu Milones Realtest und Schließfreigabe offen.
  • Status: Candidate 2026-07-25-142259 ist prepared/unreleased; es gibt keine Deploymentbehauptung. Release 2026-07-23-205700 bleibt der einzige current/deployed Stand und die rollbackfähige produktive Basis.
Einfach erklärt: Was wurde am Changelog und an den Eingaben verbessert?

Das Changelog lässt sich jetzt zuverlässig über das X, einen Klick neben den Inhalt oder die Escape-Taste schließen. Lange Einträge bleiben in einem begrenzten Bereich scrollbar, der auch mit Tastatur und Touch bedienbar ist und nicht über den sichtbaren Bildschirm hinauswächst.

Beim Öffnen merkt sich die Anwendung, ob das Spiel vorher lief oder bereits pausiert war und wohin der Tastaturfokus gehörte. Beim Schließen stellt sie diesen Zustand gemeinsam wieder her. Falls ein Browser beim Öffnen oder Schließen einen Fehler meldet und das Fenster sichtbar bleibt, wird das Auto nicht versehentlich wieder freigegeben; das sichtbare Fenster bleibt bedienbar und ein späterer Schließversuch kann sauber aufräumen.

Tastatur und Controller werden nun an einer zentralen Stelle verwaltet. Wird das Fenster verlassen, der Tab verborgen oder das Changelog geöffnet, werden aktive Fahrbefehle gelöscht. Eine dabei gehaltene Taste oder Controller-Taste löst nach der Rückkehr nichts nachträglich aus; sie muss erst losgelassen und erneut gedrückt werden. Auch ein getrennter, neu verbundener oder fehlerhaft gemeldeter Controller kann keine alte Pause-, Kamera- oder Kartenaktion wiederholen.

Dieser Candidate ist nur vorbereitet und nicht ausgerollt. Der produktive Stand 2026-07-23-205700 bleibt current, unmittelbarer Vorgänger und sichere Rollback-Basis. Issue #23 bleibt offen, bis Milone den Stand im echten Spiel bestätigt und die Schließung freigibt.

Fail-closed Input-Lifecycle
Zentrale Zustandsgrenze, die Fahrbefehle bei unklarem Browser-, Dialog- oder Controllerzustand gesperrt hält.
Suppression-Token
Eindeutiger Besitznachweis für einen Sperrgrund; erst das passende Ende gibt genau diesen Besitz wieder frei.
Blocked-until-release
Eine während der Sperre gehaltene Taste bleibt wirkungslos, bis ihr echtes Loslassen beobachtet wurde.
Gamepad Connection-Epoch
Zähler pro Controller-Slot, der einen neu verbundenen Controller von einem früheren Gerät am selben Slot unterscheidet.
Press-Edge-Synchronisation
Eine Aktion entsteht nur beim neuen Übergang von „nicht gedrückt“ zu „gedrückt“, nicht aus einem bereits gehaltenen oder alten Zustand.
Transaktionaler Rollback
Pause, Eingabesperre, Dialogsichtbarkeit, Hintergrundbedienbarkeit und Fokus werden als zusammengehöriger Zustand wiederhergestellt.

v2026-07-23-205700 Current

Technische Zusammenfassung

Der immutable Release 2026-07-23-205700 wurde produktiv ausgerollt und ist der einzige current Stand. Das laufende Image localhost/local/nyx-racer:2026-07-23-205700 besitzt die verifizierte Source-Provenienz 30d7e06353e3a85861e39370b91c2258bb2fa627. Er löste den zuvor produktiven Release 2026-07-23-132958 ab; dieser bleibt als rollbackfähiger historischer Vorgänger dokumentiert. Für Candidate 2026-07-25-142259 ist 2026-07-23-205700 der unmittelbar produktive Vorgänger und die rollbackfähige Produktionsbasis.

  • Fail-closed Retry-Lifecycle: Der native Link „Retry loading“ trägt bereits im parser-erzeugten DOM das boolesche hidden-Attribut. Initialisierung und erfolgreiche First-Frame-Readiness halten ihn außerhalb von Layout und Fokusreihenfolge; ausschließlich ein terminaler Startup-Fehler entfernt hidden, fokussiert den Link und lässt die native Navigation anklickbar.
  • CSS-Cascade-Vertrag: Eine autoritative [hidden]-Regel mit display: none !important verhindert, dass die sichtbare Klassenregel des Retry-Links die Hidden-Semantik überschreibt. Der Vertrag wird als berechnete Cascade einschließlich Priorität, Spezifität und Quellreihenfolge regressionsgetestet.
  • Controller- und Bootstrap-Terminalität: Der Controller akzeptiert nach setError keine verspätete Ready-Transition. Die Bootstrap-Grenze stellt Modalität und inert fail-closed wieder her und aktiviert den Retry-Pfad auch dann bestmöglich direkt, wenn ein untergeordneter Fehlerreporter ausfällt.
  • Polling- und Hotpath-Invariante: Der bestehende Readiness-Scheduler behält genau einen ausstehenden Animation-Frame und terminiert ohne Nachpolling. Bereits gesetztes window.__nyxReady=true erzeugt keinen Polling-Frame; der Gameplay-Frame-Hotpath und seine allocationsfreie Callback-Grenze bleiben unverändert.
  • Regressionsebenen: DOM-, Controller- und Bootstrap-Tests decken initial verborgenes Verhalten, den Ready-Zustand „Ready. Choose a game mode.“, einen sichtbaren, fokussier- und anklickbaren Fehlerfall sowie den CSS-Computed-Contract ab.
  • Status: Release 2026-07-23-205700 ist produktiv deployed und der einzige current Stand. Release 2026-07-23-132958 wurde durch seinen Rollout superseded und bleibt als rollbackfähiger Vorgänger dokumentiert; für Candidate 2026-07-25-142259 ist 2026-07-23-205700 die rollbackfähige produktive Basis.
Einfach erklärt: Warum ist „Retry loading“ jetzt nur bei einem Fehler sichtbar?

Beim normalen Öffnen und nach einem erfolgreichen Start wird „Retry loading“ vollständig ausgeblendet. Der Link belegt dann keinen Platz und kann weder mit der Tastatur noch versehentlich mit der Maus erreicht werden. Erst wenn der Start endgültig fehlschlägt, erscheint der Link, erhält den Tastaturfokus und lädt die Seite beim Aktivieren neu.

Browser bringen für hidden ein eingebautes Verhalten mit. Eine eigene Darstellungsregel für dieselbe Komponente kann dieses Verhalten jedoch überstimmen. Deshalb besitzt die Anwendung zusätzlich eine stärkere allgemeine Regel, damit ein verborgenes Element unabhängig von seiner Komponentenklasse tatsächlich ohne Layoutbox verborgen bleibt.

Ein später eintreffendes Bereitschaftssignal darf einen bereits festgestellten Startfehler nicht mehr zurücknehmen. Gleichzeitig wurde geprüft, dass für einen bereits fertigen Start kein zusätzlicher Abfrage-Frame angelegt wird und der laufende Bildpfad keine neuen temporären Callback-Objekte erhält.

Dieser Stand ist produktiv ausgerollt und current. Er löste 2026-07-23-132958 ab und ist für den vorbereiteten Candidate 2026-07-25-142259 der unmittelbare produktive Vorgänger sowie die sichere Rollback-Basis.

Boolesches hidden-Attribut
HTML-Zustand, dessen Anwesenheit ein Element unabhängig vom Attributwert als verborgen kennzeichnet.
CSS-Cascade
Browserregeln zur Auswahl der wirksamen Deklaration anhand von Herkunft, Wichtigkeit, Spezifität und Quellreihenfolge.
Computed-Contract
Regressionstest für den tatsächlich aus der Cascade resultierenden Darstellungswert statt nur für das Vorhandensein einer einzelnen Regel.
Terminaler Startup-Fehler
Endgültiger Fehlerzustand, der nicht mehr durch ein verspätetes Ready-Signal überschrieben werden darf.
Fail-closed
Fehlerstrategie, bei der Spieloberfläche und Eingaben gesperrt bleiben, bis ein sicherer Zustand ausdrücklich hergestellt ist.

v2026-07-23-195440 Superseded · Unreleased

Technische Zusammenfassung

Der immutable Candidate-Release 2026-07-23-195440 wurde nach einem Browserbefund verworfen und nie produktiv deployed. Er ist unreleased und durch 2026-07-23-205700 abgelöst (superseded); er war zu keinem Zeitpunkt current. 2026-07-23-132958 blieb während der Prüfung unverändert der einzige current und produktiv deployte Stand.

  • Modales Startmenü und Surface-Routing: Beim ersten Laden ist ein echtes modales Startmenü sichtbar. Ein realer Openworld-/Multiplayer-/Settings-Router öffnet die freie Fahrt, die Multiplayer-/Lobby-Fläche oder die Einstellungen; Career bleibt explizit als Coming Soon deaktiviert.
  • Readiness- und Gameplay-Gate: Gameplay bleibt bis zur bewussten Auswahl gesperrt, während Rendering und First-Frame-Readiness weiterlaufen. Erst nach erfolgreicher Bootstrap- und Render-Bereitschaft werden gültige Ziele freigeschaltet; terminale Startupfehler halten alle Aktionen gesperrt und bieten einen sichtbaren Retry-Pfad statt eines halb aktiven Spiels.
  • Atomare Navigationsgrenze: Surface-Wechsel folgen einer atomaren Commit→Expose→Focus-Sequenz. Schlägt Commit, Freigabe oder Fokusübergabe fehl, stellt die Rollback-Grenze Menü-Sichtbarkeit, Inert-Zustand, Pause, aktive Tabs, Konfiguration und Fokus konsistent wieder her.
  • A11y und Fokus: Das Startmenü besitzt Dialogsemantik, aria-modal, Live-Status, definierte initiale Fokusübergabe, Fokusbegrenzung sowie sichere Tastatur- und Fokus-Rückgabe. Deaktivierte Ziele bleiben für assistive Technologien eindeutig erkennbar.
  • Hotpath- und hostile-hook-Härtung: Das Gameplay-Gate liegt im Frame-Hotpath ohne Event-Simulation. Fehlerwerfende oder manipulierte Host-Hooks für Router, Readiness, Fehlerbericht und Fokus werden an kontrollierten Grenzen behandelt; terminale Fehler können nicht durch spätere Ready-Signale überschrieben werden.
  • Restscope: Persistente Accounts samt DB, ein zufälliger und ablaufender Gastname sowie vollständiges Lobby-CRUD sind nicht Bestandteil dieses Candidates. Issue #8 bleibt offen und wird durch diesen vorbereiteten Slice nicht geschlossen.
  • Status: Candidate 2026-07-23-195440 wurde nie produktiv ausgerollt, ist superseded/unreleased und durch 2026-07-23-205700 abgelöst.
Einfach erklärt: Was bringt der vorbereitete Candidate?

Beim ersten Öffnen erscheint jetzt wirklich ein Startmenü über dem Spiel. Das Auto reagiert noch nicht auf Spieleingaben, obwohl die Grafik im Hintergrund bis zum ersten fertigen Bild weiter vorbereitet wird. Erst wenn dieses Bild bereit ist und jemand einen Spielmodus auswählt, wird das Gameplay freigegeben.

Die Auswahl führt tatsächlich an unterschiedliche Ziele: Openworld öffnet die freie Welt, Multiplayer die Mehrspieler- und Lobby-Fläche und Settings die Einstellungen. Karriere ist als „Coming Soon“ sichtbar, aber noch nicht verfügbar. Wenn der Start endgültig fehlschlägt, bleiben die Schaltflächen gesperrt und ein klarer Hinweis mit erneutem Laden wird angezeigt.

Ein Wechsel wird als zusammengehöriger Vorgang behandelt: Zuerst wird das Ziel vorbereitet, dann sichtbar gemacht und zuletzt erhält es den Tastaturfokus. Geht dabei etwas schief, werden Sichtbarkeit, Pause, Auswahl und Fokus gemeinsam auf den vorherigen Zustand zurückgesetzt. Das hilft sowohl Tastaturnutzenden als auch assistiven Technologien und verhindert ein halb geöffnetes Menü.

Noch nicht enthalten sind ein dauerhaftes Konto mit Datenbank, ein zufälliger Gastname, der später abläuft, und das vollständige Erstellen, Anzeigen, Ändern und Löschen von Lobbys. Deshalb bleibt Issue #8 offen. Dieser Candidate wurde nur vorbereitet und noch nicht ausgerollt; der bisherige produktive Stand bleibt unverändert die sichere Rollback-Basis.

First-Frame-Readiness
Das Signal, dass Initialisierung und mindestens ein tatsächlich gerendertes Bild erfolgreich abgeschlossen sind.
Commit→Expose→Focus
Die feste Reihenfolge, in der ein Zielzustand übernommen, die Spielfläche freigegeben und anschließend der Tastaturfokus gesetzt wird.
Rollback-Grenze
Die transaktionale Fehlergrenze, die bei einem fehlgeschlagenen Wechsel alle bereits veränderten Oberflächen- und Eingabezustände zurücksetzt.
Hostile Hook
Ein ersetzter, unerwarteter oder fehlerwerfender Integrations-Hook, der den Startablauf trotzdem nicht in einen inkonsistenten Zustand bringen darf.
Lobby-CRUD
Die vollständigen Operationen Create, Read, Update und Delete für Mehrspieler-Lobbys.

v2026-07-23-132958

Technische Zusammenfassung

Der immutable Release 2026-07-23-132958 bündelte das vollständige technische Delta der drei Realtest-2-Slices seit dem zuvor produktiv deployten Release 2026-07-23-092248. Er war produktiv deployed; durch den Rollout von 2026-07-23-205700 wurde er abgelöst (superseded) und bleibt als rollbackfähiger historischer Vorgänger dokumentiert. Sein damaliges produktives Image sha256:180929ec0144300019dad50f9c53f7fb35b9eb09b92b9c2badb040a109b74f87 basierte auf Commit 8ddfed5722019b0aeadde236642e7446e52920b5.

  • Realtest-2 Licht: Exakt zwei fahrzeuggebundene Player-SpotLights beleuchten Straße und 3D-Geometrie; AI-Fahrzeuge erzeugen keine dynamischen Lichter und vervielfachen das Lichtbudget nicht. Die flachen Beam-/Headlight-Träger samt Alpha-Maske und der unter dem Fahrzeug sichtbaren Aura sind aus dem Renderpfad entfernt. Direkte Scheinwerfer bleiben nachts unabhängig von Reflections und Quality aktiv, werfen keine Schatten und werden ausschließlich über den Night-Faktor geregelt; die alten Trägerkoordinaten bleiben nur als unsichtbare Telemetrie erhalten.
  • Realtest-2 Audio – Turbo-Spool und Release-Kanten: Die Turbo-Spool-Last wird aus Boost, Throttle, Geschwindigkeit und RPM begrenzt berechnet und erzeugt unter Last ein zurückhaltendes hörbares Grundgeräusch. Throttle-Lift und autoritativer Boost-Release werden zu genau einem Blow-off-Cue koalesziert; zusammenfallende Kanten können keinen doppelten Cue auslösen.
  • Realtest-2 Audio – Backfire und Lifecycle: Das Backfire besitzt einen kurzen Transient mit angehobenem Mittenband, der sich gegen ein repräsentatives Motorbett absetzt. Ungültige Telemetrie, Pause und Mute konsumieren die Kantenhistorie sicher und erzeugen kein späteres Replay; bestehende fail-silent Web-Audio-Grenzen bleiben erhalten.
  • Realtest-2 Navigation – Weltmarker: Gold-orange Rauchmarker kennzeichnen den freien Wegpunkt und die noch aktiven Checkpoints. Ein begrenzter, deterministischer Partikel-Pool ist an das initiale Render-Tier und damit das Leistungsprofil beim Start angepasst und verwendet eine gemeinsame GPU-Ressource; Pause stoppt Buffer-Updates, inaktive Marker verursachen keine Frame-Uploads und Dispose räumt Geometrie, Material und Textur idempotent auf.
  • Realtest-2 Navigation – Ankunft und getrennte Zustände: Der freie Wegpunkt wird beim ersten Eintritt in einen straßenbreitenabhängigen Ankunftsradius atomar und exakt einmal gelöscht. Sein Lifecycle bleibt vom Checkpoint-Lifecycle getrennt: Wegpunktankunft konsumiert keine Rennkontrollpunkte, während abgeschlossene Checkpoints ausschließlich über den Rennfortschritt deaktiviert werden.
  • Wet-Road-Shader-Hotfix: Die Normalenabflachung für stehendes Wasser verwendet an der Shader-Injektionsstelle nonPerturbedNormal anstelle von geometryNormal; letzteres wird erst in einem späteren Shader-Chunk deklariert und ist an der Injektionsstelle noch nicht im GLSL-Gültigkeitsbereich (lexikalischer Scope). Der Hotfix erhält den Nässeeffekt und beseitigt die ungültige Variablenreferenz. Ein Regressionstest expandiert dafür die Shader-Chunks der eingebetteten Three.js-Version und prüft die Deklaration innerhalb von main() vor der Injektionsstelle.
  • Status: Release 2026-07-23-132958 war produktiv deployed und wurde durch den Rollout von 2026-07-23-205700 superseded; er bleibt als rollbackfähiger historischer Vorgänger dokumentiert. Die ältere Beziehung zu 2026-07-23-092248 bleibt unverändert erhalten.
Einfach erklärt: Was ist im aktuellen Release verbessert?

Zwei echte Scheinwerfer am Spielerauto leuchten jetzt direkt auf Straße, Gebäude und andere räumliche Objekte. Computerautos erzeugen dabei keine zusätzlichen Lichter. Die flache Leuchtfläche unter dem Auto wurde entfernt, damit keine helle Aura mehr mitfährt. Das direkte Licht bleibt nachts auch bei ausgeschalteten Reflexionen und niedriger Grafikqualität erhalten.

Der Turbolader ist bei kräftigem Gas als leises Grundgeräusch hörbar. Beim Loslassen des Gases oder beim Ende des Boosts erklingt das Ablassgeräusch genau einmal, selbst wenn beides gleichzeitig passiert. Eine Fehlzündung hat nun einen kurzen, deutlicheren Knall, der nicht im Motorgeräusch untergeht. Wird das Spiel in einer Pause stumm oder kommen ungültige Fahrwerte an, entsteht daraus später kein nachgeholtes Geräusch.

Goldorange Rauchwolken zeigen das frei gesetzte Ziel und die noch offenen Kontrollpunkte schon in der Spielwelt. Dafür wird ein fester Vorrat an Partikeln verwendet, dessen Größe zur anfänglichen Leistung beim Start passt. In einer Pause werden keine unnötigen Bilddaten übertragen, und beim Beenden wird alles genau einmal aufgeräumt.

Kommt das Auto breit genug an das gesetzte Ziel heran, verschwindet es beim ersten Eintritt genau einmal. Die Kontrollpunkte eines Rennens bleiben davon unabhängig und verschwinden nur entsprechend dem Rennfortschritt.

Bei der Darstellung nasser Straßen greift der Shader jetzt auf einen an dieser Stelle gültigen Normalenwert zurück. Zuvor wurde ein Wert verwendet, den das Shader-Programm erst in einem späteren Abschnitt kennt. Dadurch bleibt der gewünschte Nässeeffekt erhalten, ohne an dieser Stelle auf einen noch unbekannten Wert zuzugreifen.

Dieser Stand war produktiv ausgerollt. Der spätere Rollout von 2026-07-23-205700 löste ihn ab; er bleibt als rollbackfähiger historischer Vorgänger verfügbar. Zuvor hatte 2026-07-23-132958 den Release 2026-07-23-092248 abgelöst.

Player-SpotLight
Eines der exakt zwei echten, am Spielerfahrzeug befestigten Three.js-Lichter, die räumliche Oberflächen direkt beleuchten.
Turbo-Spool-Last
Ein begrenzter Lastwert aus Gasstellung, Geschwindigkeit, Drehzahl und Boost, der das laufende Turbogeräusch steuert.
Transient / Mittenband
Der kurze Energieanstieg am Anfang des Knalls und sein gut hörbarer mittlerer Frequenzbereich.
Koaleszierte Release-Kante
Gleichzeitig erkannte Ablassereignisse werden zu genau einem Cue zusammengeführt.
Begrenzter Partikel-Pool
Ein fester, wiederverwendeter Vorrat für alle Rauchmarker statt neuer Objekte pro Bild.
Straßenbreitenabhängiger Ankunftsradius
Der sichere Zielbereich berücksichtigt die Breite der nächstgelegenen Straße und einen festen Mindestabstand.
GLSL-Gültigkeitsbereich (lexikalischer Scope)
Der Abschnitt eines Shader-Programms, in dem eine deklarierte Variable verwendet werden darf; nonPerturbedNormal ist an der Hotfix-Stelle bereits gültig, geometryNormal dagegen noch nicht.

v2026-07-23-092248

Technische Zusammenfassung

Der immutable Release 2026-07-23-092248 bündelt das technische Delta seit 2026-07-23-001526 und war produktiv deployed. Durch den Rollout von 2026-07-23-132958 wurde er abgelöst (superseded); er bleibt als rollbackfähiger produktiver Vorgänger verfügbar.

  • Breakaway-Props und Sparks: Kollidierte Laternen und kleine Bäume wechseln deterministisch von intact über falling zu down. Nur aktive Breakaway-Props werden über eine O(1)-verwaltete Aktivliste aktualisiert; ein begrenzter, wiederverwendeter Spark-Pool erzeugt einmalige Funkenereignisse und wird bei Race-Restart oder Teardown ohne stale Referenzen zurückgesetzt.
  • Wet-Aura und Straßenclutter: Unsourced additive Wet-Aura-Träger, Lichtpfützen, generierte Zebrastreifen und Stopplinien sind entfernt. Die gerichtete Scheinwerferoptik und sichtbare Laternenköpfe bleiben erhalten; damit wird die Straße nicht durch unbelegte omnidirektionale Glows verfälscht.
  • Nitro, Backfire und Audio: Nitro-Release und Backfire werden an autoritativen Zustandskanten jeweils exakt einmal ausgelöst. Web-Audio-Erzeugung, Scheduling und einzelne AudioParam-Writes arbeiten fail-silent, sodass gesperrtes oder fehlerhaftes Audio weder Gameplay noch den nächsten Frame unterbricht und Lifecycle-Übergänge keine alten Cues wiederholen.
  • Map-Outline-Provenienz: Der Kartenumriss ist als visuelle Approximation aus dem referenzierten Screenshot issue6-comment141-red-route dokumentiert. Seine Anker verweisen auf vorhandene Vertices des lokal gepinnten OpenStreetMap-Assets; Referenz, Unsicherheit und Quellenbezug bleiben maschinenlesbar erhalten.
  • Fahrzeit-schnellste fahrbare Route: Minimap und Fullscreen-Map verwenden dieselbe über das Straßennetz fahrbare Route. Die Suche minimiert Fahrzeit statt Luftlinie oder bloßer Distanz, berücksichtigt Straßengeschwindigkeiten und Einbahnrichtungen und liefert für nicht erreichbare Ziele keine irreführende Teilroute.
  • Navigationsdarstellung: Es gibt keine Navigationssymbole in der Spielwelt. Genau ein GUI-Richtungspfeil zeigt zum nächsten gültigen Routenabschnitt; Minimap und Fullscreen-Map zeichnen die Route innerhalb des belegten Kartenumrisses.
  • Fail-soft Map-/Performance-Lifecycle: Fehlende oder ungültige optionale Kartendaten ergeben einen leeren Graphen statt eines Startabbruchs. Null-Routen werden sicher konsumiert, Routenberechnungen bewegungs- und zeitgebunden gecacht, temporäre Arrays wiederverwendet und Breakaway-, Spark-, Navigations- sowie Audiozustände auf allen Restart-Pfaden gemeinsam bereinigt.
  • Status: Dieser Release war produktiv deployed, ist seit dem Rollout von 2026-07-23-132958 superseded und bleibt rollbackfähig.
Einfach erklärt: Was wurde für den nächsten Stand verbessert?

Laternen und kleine Bäume können bei einem Zusammenstoß jetzt kontrolliert umfallen und dabei einmal Funken erzeugen. Danach werden nur noch die tatsächlich umfallenden Objekte weiterbewegt und beim Neustart vollständig aufgeräumt. Gleichzeitig wurden unbelegte Leuchtflächen und künstlich erzeugte Straßendetails entfernt. Die nach vorn gerichteten Scheinwerfer und die sichtbaren Köpfe der Straßenlaternen bleiben jedoch erhalten.

Nitro und Fehlzündungen spielen ihr Geräusch jeweils nur für das passende echte Ereignis ab. Wenn der Browser Ton blockiert oder eine Tonfunktion fehlschlägt, fährt das Spiel ohne Unterbrechung weiter. Alte Geräusche werden nach Pause, Neustart oder Rennwechsel nicht erneut abgespielt.

Der Kartenrand folgt nachvollziehbar der roten Linie aus dem referenzierten Screenshot und ist mit Punkten aus den lokal gespeicherten Kartendaten verknüpft. Ein gesetztes Ziel erhält die Route mit der kürzesten erwarteten Fahrzeit auf tatsächlich befahrbaren Straßen, einschließlich Einbahnstraßen. Dieselbe Route ist auf der kleinen und der großen Karte sichtbar. Auf der Straße schweben keine Richtungssymbole; nur ein Zielpfeil in der Bedienoberfläche weist zum nächsten Routenabschnitt. Fehlen optionale Kartendaten oder ist ein Ziel nicht erreichbar, bleibt das Spiel bedienbar und zeigt keine erfundene Teilroute.

Dieser Stand war produktiv deployed. Der Rollout von 2026-07-23-132958 hat ihn abgelöst; er bleibt als dokumentierter, rollbackfähiger Vorgänger verfügbar.

Breakaway-Lifecycle
Die festgelegte Folge intact (steht), falling (fällt) und down (liegt), einschließlich vollständigem Reset der aktiven Referenzen.
Spark-Pool
Ein fester Vorrat wiederverwendbarer Funkenobjekte; dadurch entstehen bei Kollisionen keine unbegrenzt wachsenden Renderressourcen.
Fail-silent Audio
Ein Audiofehler wird lokal abgefangen und beendet weder Spielablauf noch Bildaktualisierung; unabhängige Tonparameter können weiter aktualisiert werden.
Screenshot-Provenienz
Der dokumentierte Bezug zwischen dem Kartenumriss, dem konkreten Referenzbild, seiner Unsicherheit und verifizierbaren Ankerpunkten in den lokalen Quelldaten.
Fahrzeit-schnellste fahrbare Route
Der gültige Weg im Straßengraphen mit der geringsten erwarteten Fahrzeit unter Berücksichtigung von Geschwindigkeit und Einbahnrichtung.
Fail-soft Lifecycle
Optionale Karten- oder Audiofunktionen dürfen kontrolliert ausfallen; Cache, Pools und Übergangszustände werden trotzdem begrenzt und zuverlässig zurückgesetzt.

v2026-07-23-001526

Technische Zusammenfassung

Der immutable Release 2026-07-23-001526 bündelte transparent das vollständige Delta seit 2026-07-22-142338 und war produktiv deployed. Mit dem Rollout von 2026-07-23-092248 wurde er regulär zum historischen produktiven Vorgänger; 2026-07-23-092248 ist weiterhin current.

  • Frontlicht: Eine weiche Projektion mit zwei überlappenden Scheinwerfer-Loben in einer gemeinsam genutzten RGBA-Alpha-Maske ersetzt die geometrisch hart begrenzten Lichtflächen. Laterale und longitudinale Falloffs sowie linear gefilterte Übergänge vermeiden sichtbare Kanten; der idempotente Teardown gibt die geteilte Textur exakt einmal frei.
  • Pause-Settings Graphics / Controls / Tuning: Die drei Einstellungsgruppen sind im Pause-Dialog bedienbar. Modal-, Focus-, Dialog- und Rollback-Semantik behandeln Öffnen, Fokusübergabe, Schließen und Fehler transaktional, sodass der vorherige Pause-, Dialog- und Fokuszustand tatsächlich wiederhergestellt wird.
  • Turbo-/Boost-Audio: Das synthetische Boost-Noise ist enttonalisiert und bleibt als breitbandiges Geschwindigkeitsgeräusch wahrnehmbar. Der Release-Cue ist dedupliziert, sodass ein tatsächlicher Boost-Release genau einen Cue auslöst.
  • Schaltkaskadenfix: Ein einzelner Fahrzustandswechsel kann keine Kaskade mehrerer Hochschaltungen im selben Update auslösen; die Gangfolge bleibt schrittweise und nachvollziehbar.
  • Navigation: Die Minimap zeichnet die Route zum aktiven Ziel; zusätzlich zeigt genau ein GUI-Richtungspfeil die Fahrtrichtung an. Die Fahrbahn erhält dafür keine Navigationsmarkierungen.
  • Landmarks: 6 echte Landmark-Straßenschilder sind an ihren zugehörigen Weltpositionen und Straßenbezügen integriert, statt nur generische Dekoration zu zählen.
  • Laternenkollision: Die Mastkollision wird pro akzeptierter Laterne aus derselben akzeptierten Platzierung registriert; verworfene Laternen erzeugen keinen unsichtbaren Collider.
  • Scope: Issue #6 bleibt ein Teilslice; Issue #11 bleibt ebenfalls ein Teilslice. Beide Issues sind damit weder vollständig umgesetzt noch fachlich geschlossen.
  • Status: Dieser Release ist produktiv deployed und bleibt bis zum tatsächlichen Rollout eines Nachfolgers current; er ist nicht superseded.
Einfach erklärt: Was ist seit dem produktiven Stand neu?

Das Licht der Scheinwerfer endet nicht mehr an harten Formen: Zwei weiche Lichtbereiche laufen sichtbar ineinander und werden am Rand allmählich dunkler. Im Pause-Menü stehen jetzt Grafik, Steuerung und Fahrabstimmung zusammen bereit. Falls beim Öffnen oder Schließen eines Dialogs etwas fehlschlägt, werden Dialog, Pause und Fokus wirklich auf ihren vorherigen Zustand zurückgesetzt, damit weder Eingaben noch Auswahl an einer halb geöffneten Ansicht hängen bleiben.

Beim Turbo klingt das Rauschen weniger wie ein gleichbleibender Ton, und das kurze Signal beim Loslassen wird nur einmal abgespielt. Der Schaltkaskadenfix verhindert eine Kaskade mehrerer Schaltungen in einem einzigen Aktualisierungsschritt. Sechs echte Landmark-Straßenschilder machen konkrete Orte erkennbar. Außerdem erhält jeder akzeptierte Laternenmast genau die passende Kollision, während eine verworfene Laterne kein unsichtbares Hindernis hinterlässt.

Bei einem aktiven Ziel zeigt die Minimap die Route. Ein einzelner GUI-Richtungspfeil weist zusätzlich die Richtung; auf der Fahrbahn werden dafür keine Navigationssymbole eingeblendet.

Dieser Stand war produktiv deployed und ist seit dem Rollout von 2026-07-23-092248 historischer Vorgänger. Die Arbeiten aus #6 und #11 bleiben Teilslices: Sie lösen nur die hier genannten Teile und erklären die beiden größeren Aufgaben nicht für abgeschlossen.

Zwei-Loben-Alpha-Maske
Eine weich gefilterte Transparenzschablone, in der die Lichtbereiche des linken und rechten Scheinwerfers überlappen und zu den Rändern auslaufen.
Modal-, Fokus- und Dialog-Rollback
Öffnen und Schließen gelten als zusammenhängende Zustandsänderung; schlägt ein Schritt fehl, werden Dialogsichtbarkeit, Spielpause und Tastaturfokus gemeinsam zurückgesetzt.
Enttonalisiertes Noise
Ein breitbandigeres Geräusch ohne störend hervortretende feste Tonhöhe.
Release-Cue-Deduplizierung
Das kurze akustische Signal beim Ende des Boosts wird pro tatsächlichem Loslassen nur einmal ausgelöst.
Akzeptierte Laterne
Eine Laterne, deren Platzierung alle Abstands- und Weltregeln erfüllt und deshalb zusammen mit der Kollision ihres Masts übernommen wird.

v2026-07-22-154758

Technische Zusammenfassung

Der technisch vorbereitete Zwischenstand 2026-07-22-154758 enthielt ausschließlich den geprüften und reviewten Frontlicht-Slice als Reaktion auf Milos Hinweis zum eckigen Altstand. Er wurde nie produktiv bereitgestellt und ist unreleased durch 2026-07-23-001526 abgelöst; eine Benutzerabnahme wird nicht behauptet.

  • Weiche Projektion: Die bisherigen harten Trapez- und Ellipsengeometrien der projizierten Frontlichtflächen sind durch eine einmalig erzeugte, linear gefilterte RGBA-Alpha-Maske ersetzt. Zwei weich überlappende Scheinwerfer-Loben bilden darin einen gemeinsamen Lichtkegel.
  • Falloff: Die Alpha-Maske reduziert die Deckkraft sowohl seitlich als auch entlang der Fahrtrichtung weich, statt die Projektion an geometrischen Kanten abrupt abzuschneiden.
  • Abgrenzung: Die vorhandenen SpotLights, Fahrtrichtung und Yaw sowie sämtliche Night-, Wet- und Quality-Gates bleiben unverändert; angepasst wird nur die Darstellung der projizierten Frontlichtflächen.
  • Lebenszyklus: Beide Frontlichtflächen verwenden dieselbe Textur. Der idempotente Render-Teardown gibt diese gemeinsame Ressource exakt einmal frei.
  • Status: Implementierung und Regressionen sind technisch geprüft und reviewt. Milo hatte ausschließlich die eckige Darstellung des Altstands bemängelt; eine produktive Bereitstellung oder vollständige Abnahme wird nicht behauptet.
Einfach erklärt: Warum wirkt das Frontlicht jetzt weicher?

Die sichtbaren Lichtflächen vor dem Auto endeten bisher an klar erkennbaren geraden beziehungsweise runden Rändern. Genau diesen eckigen Altstand hatte Milo bemängelt. Nun wird eine einmal vorbereitete Helligkeitsschablone verwendet: Zwei sanft ineinanderlaufende Scheinwerferbereiche werden zu den Seiten und nach vorn allmählich schwächer. Dadurch entsteht ein weicher Übergang zur dunklen Straße statt einer abrupten Kante.

Die tatsächlich leuchtenden Scheinwerfer, die Ausrichtung am fahrenden Auto und die Regeln für Nacht, Nässe und Grafikqualität wurden dabei nicht verändert. Beide sichtbaren Frontlichtflächen teilen sich dieselbe Schablone; beim Beenden der Darstellung wird sie genau einmal aufgeräumt. Der Stand wurde technisch geprüft und reviewt, ist aber noch nicht produktiv und noch nicht als vollständig von Benutzern abgenommen dokumentiert.

RGBA-Alpha-Maske
Eine Bildschablone, deren Transparenzwert für jeden Punkt festlegt, wie stark die Lichtfläche dort sichtbar ist; die Farbkanäle werden gemeinsam mit diesem Transparenzverlauf gespeichert.
Lineare Filterung
Eine weiche Zwischenwertbildung zwischen benachbarten Punkten der Schablone, damit beim Vergrößern keine harten Pixelstufen entstehen.
Scheinwerfer-Lobe
Einer der zwei länglichen Helligkeitsbereiche, die den linken und rechten Scheinwerfer abbilden und sich in der Mitte weich überlappen.
Falloff
Das kontrollierte Schwächerwerden des sichtbaren Lichts zu den Seiten und entlang der Fahrtrichtung.
Idempotenter Teardown
Das sichere Aufräumen der Darstellungsressourcen, das auch bei wiederholtem Aufruf keine Ressource mehrfach freigibt.

v2026-07-22-142338

Technische Zusammenfassung

Das immutable superseding Release 2026-07-22-142338 bereitet ausschließlich die Issue-#2-Korrektur aus Milos fehlgeschlagenem Realtest des produktiven Releases 2026-07-22-105819 (Commit 16b792d) vor. Dieser Eintrag behauptet weder eine Bereitstellung noch einen Candidate-Status; Issue #2 bleibt bis zu erfolgreichem Realtest und Schließfreigabe offen.

  • Realtest-Anlass: Milo stellte fest, dass die fahrzeuggebundenen Frontlicht- und Wet-Road-Decals bei gedrehtem Fahrzeug gegenüber der sichtbaren Fahrtrichtung gespiegelt ausgerichtet waren.
  • Korrektur: Beam, Headlight-Glow, Chase-Glow, Taillight-Glow und Rear Streak verwenden für ihre Mesh-Rotation jetzt visibleYaw mit unverändert aus der sichtbaren Renderpose berechneten Positionen. Damit liegen ihre Längsachsen parallel zur sichtbaren Fahrzeugrichtung, und der Frontlichtkegel verbreitert sich nach vorn statt in die gespiegelte Richtung.
  • Echte Lichter unverändert: Die realen Three.js-SpotLights und ihre wetterunabhängigen Sichtbarkeits- und Qualitybudgets werden nicht geändert; korrigiert werden ausschließlich die Fahrzeuglicht- und Wet-Reflection-Decals.
  • Regression: Tests transformieren die echte Beam- und Decal-Geometrie über Three.js-matrixWorld bei positiven und negativen nicht-kardinalen Yaws und vergleichen ihre Weltachsen mit der sichtbaren Vorwärtsrichtung.
  • Verifikation: 323 Python- und 302 Node-Tests bestanden; JavaScript-Syntax, Python-Compile, JSON/YAML-Parsing, Release-Marker-Konsistenz und git diff --check sind fehlerfrei.
Einfach erklärt: Warum folgt das Licht jetzt richtig?

Milos Realtest zeigte, dass die Lichtflächen auf der Straße zwar an der richtigen Stelle lagen, beim Drehen des Autos aber in die spiegelverkehrte Richtung zeigten. Ursache war ein umgekehrtes Vorzeichen bei der Drehung dieser flachen Geometrien. Jetzt nutzen sie dieselbe sichtbare Drehung wie das Fahrzeug: Der Frontlichtkegel öffnet sich nach vorn, und die länglichen Reflexionsflächen verlaufen entlang der sichtbaren Fahrtrichtung.

Die echten Scheinwerfer, die die Umgebung als SpotLights beleuchten, bleiben unverändert. Automatische Tests drehen echte Three.js-Geometrien in beide Richtungen und prüfen ihre Weltachsen. Issue #2 bleibt trotzdem offen, bis Milo den neuen Stand erfolgreich im Spiel getestet und die Schließung freigegeben hat; dieser Eintrag meldet keine Auslieferung und keinen Candidate.

Decal
Eine flache, transparente Leuchtfläche auf der Straße; sie ist kein echtes Licht.
visibleYaw
Die Drehung des im aktuellen Bild sichtbaren Fahrzeugmodells um die senkrechte Achse.
matrixWorld
Die Three.js-Matrix, die lokale Geometriepunkte einschließlich Position und Drehung in Weltkoordinaten überführt.

v2026-07-22-105819

Technische Zusammenfassung

Das immutable Release 2026-07-22-105819 bereitet den Straßen-Cleanup als Nachfolger des produktiven Releases 2026-07-21-205700 (Commit ccd8eb4) vor. Es liefert einen eng abgegrenzten Teil-Slice aus Issue #6; Issue #6 ist damit ausdrücklich weder vollständig erledigt noch geschlossen.

  • Schachtdeckel: Alle 1.046 zuvor hochstehenden Instanzen liegen jetzt horizontal auf der Asphaltoberfläche. Die Zylindergeometrie nutzt ihre native Y-Achse ohne zusätzliche X-Rotation, ist exakt 12 mm stark und wird über die explizite Asphalt-Höhe samt 2-mm-Z-Fighting-Abstand gebunden.
  • Fahrbahnmarkierungen: Alle 168 dreidimensionalen ConeGeometry-Pfeile wurden durch echte plane ShapeGeometry-Markierungen in der XZ-Ebene ersetzt. Ihre Oberflächennormalen zeigen nach oben; Skalierung und Yaw bleiben auf der Fahrbahn erhalten.
  • TDD-Vertrag: Regressionen prüfen lokale und transformierte AABBs, 12-mm-Dicke und Asphaltabstand, aufwärts gerichtete Normalen, Y-only-Yaw bei 0° und 90°, unveränderte Platzierungsbedingungen sowie die exakten Instanzzahlen 1.046 und 168.
  • Abgrenzung: Der Release ändert weder Road-Graph noch Collision, Streaming, Traffic Signals oder die Anzahl und Platzierungslogik der betroffenen Straßendetails.
  • Verifikation: 323 Python- und 301 Node-Tests bestanden; JavaScript-Syntax, Python-Compile, JSON/YAML-Parsing, Release-Konsistenz und git diff --check sind fehlerfrei.
Einfach erklärt: Was wurde auf der Straße bereinigt?

Die 1.046 Schachtdeckel ragten bisher wie aufgestellte Scheiben aus der Straße. Jetzt liegen sie flach, sind nur 12 Millimeter dick und sitzen knapp über der Asphaltfläche, damit sie sichtbar bleiben, ohne zu flackern.

Außerdem waren 168 Richtungspfeile kleine dreidimensionale Kegel. Sie sind nun flache, nach oben sichtbare Fahrbahnmarkierungen. Automatische Geometrietests prüfen Größe, Höhe, Oberseite, Drehung und Anzahl. Dies ist nur ein enger Straßenoberflächen-Teil von Issue #6; andere Arbeiten des Issues sind nicht als erledigt markiert, und Straßennetz, Kollisionen, Streaming sowie Ampeln bleiben unverändert.

AABB
Eine achsenparallele Begrenzungsbox, mit der Tests Breite, Länge und Höhe einer Geometrie vor und nach ihrer Platzierung messen.
ShapeGeometry
Eine flache, aus einem zweidimensionalen Umriss erzeugte Geometrie; hier bildet sie die Markierung ohne Kegelvolumen oder senkrechte Seitenwände.
Yaw
Die Drehung um die senkrechte Y-Achse, mit der die flache Markierung entlang der jeweiligen Fahrbahn ausgerichtet wird.

v2026-07-21-205700

Technische Zusammenfassung

Release 2026-07-21-205700 ist der superseding Hotfix für vier Befunde aus Milos Realtest des produktiven Releases 2026-07-21-174522. Die Korrekturen betreffen die Vollbildkarte und Navigation aus Issue #3 sowie die im selben Release enthaltenen Licht- und Renderpose-Arbeiten aus Issues #2 und #10. Alle drei Issues bleiben für die abschließende Realtest- und Schließfreigabe ausdrücklich offen.

  • Wegpunktführung und Kartenlesbarkeit: Frei gesetzte Wegpunkte steuern nun konsistent HUD, Minimap und den GUI-Richtungspfeil, auch während eines Rennens. Entfernung und Abbiegerichtung folgen der interpolierten sichtbaren Fahrzeugpose; Wegpunkte außerhalb der Minimap erhalten einen eindeutigen Randpfeil. Straßennamen werden entlang des Straßenverlaufs ausgerichtet und nur vollständig innerhalb des Viewports gezeichnet.
  • Fahrzeuggebundene Scheinwerfer: Der sichtbare Lichtkegel, die Scheinwerferintensität und die nassen Straßenreflexionen sind an die interpolierte Fahrzeugpose sowie den Nachtfaktor gekoppelt. Dadurch bleiben die Lichter am Fahrzeug, sind nachts klar erkennbar und verschwinden nicht fälschlich beziehungsweise lösen sich bei Kamerainterpolation nicht vom Fahrzeug.
  • Navigation und Kartendaten: Race- und Wegpunktziele werden zentral und deterministisch priorisiert; Minimap, HUD und GUI-Richtungspfeil verwenden dasselbe Ziel und dieselbe Renderpose. Die vollständige Kniprodestraße stammt aus einem versionierten minimalen OpenStreetMap-Snapshot mit reproduzierbarer Projektion, Hash- und Provenienzprüfung statt aus einem nicht archivierten API-Ausschnitt.
  • Attribution: Die OpenStreetMap-Urheber- und Lizenzattribution ist sowohl dauerhaft in der Spieloberfläche als auch direkt in der Vollbildkarte sichtbar und sicher verlinkt.
  • Release-Status: Dieser Hotfix ersetzt 2026-07-21-174522; der vorherige Release bleibt als tatsächlich produktiv bereitgestellte Version in der Historie erhalten. Issues #2, #3 und #10 werden mit diesem Release nicht geschlossen.
  • Verifikation: 323 Python- und 298 Node-Tests bestanden; 23 JSON- und 2 YAML-Dateien wurden erfolgreich geparst, die JavaScript-Syntax sowie git diff --check sind fehlerfrei.
Einfach erklärt: Was wurde im Realtest korrigiert?

Ein auf der großen Karte gesetztes Ziel hilft jetzt während der Fahrt wirklich weiter: Das HUD zeigt Entfernung und Richtung, die kleine Karte markiert auch Ziele außerhalb ihres Ausschnitts, und die Pfeile auf der Straße weisen zum selben Ziel. Alle Anzeigen orientieren sich an der Position und Richtung des Autos, die im aktuellen Bild tatsächlich sichtbar sind.

Die Scheinwerfer bleiben nun sichtbar am Fahrzeug und passen zu Nacht, Grafikqualität und nasser Straße. Straßennamen sind auf der großen Karte besser ausgerichtet, die Kniprodestraße beruht auf einer archivierten und prüfbaren OpenStreetMap-Quelle, und der vorgeschriebene Hinweis auf die Kartendaten ist direkt in Spiel und Karte sichtbar. Die offenen Issues #2, #3 und #10 bleiben offen, bis Milo den Hotfix im echten Spiel bestätigt und ihre Schließung freigibt.

Superseding Hotfix
Ein neuer, vollständiger Korrekturstand, der eine bereits produktiv eingesetzte Version ersetzt, ohne deren Auslieferung aus der Historie umzudeuten.
Interpolierte Renderpose
Die weich berechnete Position und Richtung des Autos, die im aktuellen Bild sichtbar ist. Navigation, Minimap und Fahrzeuglicht verwenden jetzt gemeinsam diesen Stand.
Geodaten-Provenienz
Der nachvollziehbare Herkunftsnachweis der Kartendaten mit archivierter Quelldatei, Abrufadresse, Prüfsumme, Filterregeln und reproduzierbarer Umrechnung in Spielkoordinaten.
Attribution
Der sichtbare Urheber- und Lizenzhinweis für die verwendeten OpenStreetMap-Daten.

v2026-07-21-174522

Technische Zusammenfassung

Release 2026-07-21-174522 ergänzte die in Issue #3 angeforderte Vollbildkarte und bündelte die Korrekturen aus Issues #2 und #10. Der Release wurde produktiv bereitgestellt und anschließend durch Milos Realtest geprüft; dessen vier Befunde werden im superseding Hotfix 2026-07-21-205700 korrigiert. Alle drei Issues bleiben bis zur erneuten Realtest- und Schließfreigabe offen.

  • Vollbildkarte: M beziehungsweise Gamepad-Select öffnet eine semantische Dialogkarte mit den kanonischen Straßenverläufen und vorhandenen Straßennamen. Gameplay-Eingaben werden während der Kartenansicht isoliert.
  • Player und Waypoints: Die sichtbare Fahrzeugpose wird nordorientiert mit Richtungsmarker dargestellt. Maus, Touch und ein deterministischer Tastatur-Cursor können Wegpunkte atomar setzen, verschieben und löschen; außerhalb des Kartenausschnitts bleibt der Player als geklemmter Randmarker mit Richtungsindikator sichtbar.
  • Robuste Runtime: Geometrie, IDs, Koordinaten, Projektionsgrenzen und Adaptereffekte werden fail-closed validiert. Öffnen/Schließen und Pause/Resume besitzen transaktionale Rollbacks; statische Kartenebenen werden gecacht und dynamische Redraws auf einen Frame zusammengeführt.
  • Enthaltene Vorreleases: Issue #2 bindet Straßenlicht-Reflexionen korrekt an Regen und Reflections sowie an die interpolierte Renderpose. Issue #10 führt Fahrzeug und Kamera über dieselbe Fixed-Step-interpolierte Pose.
  • Verifikation: 320 Python- und 290 Node-Tests bestanden; Spec-Review PASS, Quality-Review APPROVED.
Einfach erklärt: Was wurde besser?

Während der Fahrt lässt sich jetzt mit M oder der Select-Taste am Controller eine große Karte öffnen. Sie zeigt die Straßen, vorhandene Straßennamen und die Position samt Blickrichtung des eigenen Fahrzeugs. Liegt das Auto außerhalb des sichtbaren Kartenausschnitts, zeigt ein Marker am Kartenrand weiterhin, in welcher Richtung es liegt.

Ein Zielpunkt kann per Maus, Touch oder Tastatur gesetzt, verschoben und wieder gelöscht werden. Die Karte pausiert ein laufendes Spiel nur für ihre eigene Anzeige und gibt es beim Schließen wieder frei. Zusätzlich enthält dieses produktiv bereitgestellte Release die Korrekturen für trockene Straßenreflexionen und die unruhige Kamera. Milos anschließender Realtest ergab vier weitere Befunde, die der Hotfix 2026-07-21-205700 korrigiert; die betroffenen Issues bleiben bis zur Bestätigung offen.

Kanonische Straßengeometrie
Die Karte zeichnet dieselben geprüften Straßen- und Namensdaten, die bereits zur Spielwelt gehören, statt eine zweite erfundene Karte zu pflegen.
Nordorientierte Projektion
Die Karte bleibt nach Norden ausgerichtet und rechnet Weltkoordinaten reproduzierbar in Bildkoordinaten um.
Transaktionaler Dialogzustand
Öffnen, Pausieren, Schließen und Fortsetzen werden als zusammengehörige Zustandsänderung behandelt; bei einem Fehler wird der vorherige konsistente Zustand wiederhergestellt.
Statischer Layer-Cache
Straßen und Beschriftungen werden nur bei Bedarf neu gezeichnet. Bewegliche Marker werden getrennt aktualisiert, damit die Karte nicht unnötig Rechenzeit verbraucht.
Off-map-Randmarker
Wenn das Fahrzeug außerhalb des sichtbaren Ausschnitts liegt, wird sein Marker an den Kartenrand gesetzt und zeigt weiter in die tatsächliche Richtung.

v2026-07-21-161504

Technische Zusammenfassung

Release 2026-07-21-161504 adressiert die in Issue #2 gemeldeten falschen Wet-Reflexionen der Fahrzeuglichter. Das Issue bleibt bis zu Milos Realtest und Schließfreigabe offen; dieser Eintrag dokumentiert keine produktive Bereitstellung.

  • Root Cause: Die additiven Straßen-Glow- und Streak-Meshes waren nur an Reflections und Quality gekoppelt und blieben dadurch auch bei trockener Straße sichtbar. Ihre Positionen folgten außerdem direkt der Physikpose statt der interpolierten sichtbaren Modellpose.
  • Wet-Reflection-Policy und Qualitybudget: Additive Road-Meshes sind ausschließlich bei rain === true && reflections === true aktiv. Die Road-Glow-Meshes beginnen ab Quality 70 mit dem Faktor 0,58 bis unter 90 und Faktor 1 ab 90; der Rear Streak beginnt ab Quality 50.
  • Echte Fahrzeuglichter: chaseFill und die Lichter des Vehicle-Rigs bleiben wetterunabhängig und behalten ihre bisherigen Qualitybudgets Q70 beziehungsweise Q85.
  • Renderpose: Position und Yaw der Straßenreflexionen werden aus der sichtbaren player.model-Position und -Rotation abgeleitet, sodass sie der interpolierten Darstellung des Fahrzeugs folgen.
  • Engineering: Ein Three.js-freier, caller-owned und allocation-stabiler Helper bündelt die gemeinsame Policy. Strikte fail-closed Booleans sowie eine atomare Domainvalidierung für Quality 0..120, nichtnegative Geschwindigkeit und Brake/Drift 0..1 verhindern Teilmutationen bei ungültigen Eingaben; 10.000-Identity-Regressionen sichern die Wiederverwendung derselben Ergebnisobjekte.
  • Verifikation: 320 Python- und 264 Node-Tests bestanden.
Einfach erklärt: Was wurde besser?

Die farbigen Lichtflächen unter und hinter dem Auto sollten nasse Straße darstellen, waren bisher aber auch auf trockener Straße zu sehen. Jetzt erscheinen diese Flächen nur, wenn Regen und Reflexionen ausdrücklich eingeschaltet sind. Je nach gewählter Grafikqualität werden sie abgestuft dargestellt; die echten Fahrzeuglichter funktionieren weiterhin unabhängig vom Wetter mit ihren bisherigen Qualitätsgrenzen.

Die Lichtflächen folgen nun genau der Position und Richtung des Autos, das im aktuellen Bild sichtbar ist, statt der gröberen Position aus der Fahrphysik. Ein gemeinsamer, streng prüfender Helfer berechnet das Ergebnis ohne laufend neue Objekte anzulegen. Automatische Tests prüfen auch 10.000 Aktualisierungen mit denselben Ergebnisobjekten. Issue #2 bleibt offen, bis Milo die Korrektur im echten Spiel getestet und die Schließung freigegeben hat; eine produktive Auslieferung wird hier nicht behauptet.

Additives Straßen-Reflexionsmesh
Eine transparente, leuchtend über die Straße gezeichnete Fläche für den Eindruck von reflektiertem Fahrzeuglicht. Sie ist kein echtes Licht und wird nun nur bei ausdrücklich aktivem Regen und aktivierten Reflexionen angezeigt.
Interpolierte Renderpose
Die für das aktuelle Bild weich berechnete sichtbare Position und Richtung des Fahrzeugmodells zwischen zwei Physikschritten.
caller-owned/allocation-stabil
Der aufrufende Code stellt die Ergebnisobjekte bereit, und der Helper aktualisiert immer dieselben Objekte, statt pro Bild neue Arrays oder Objekte anzulegen.
fail-closed
Regen und Reflexionen gelten nur beim exakten Boolean-Wert true als aktiv; fehlende, andersartige oder falsche Werte schalten den Effekt sicher aus.
Atomare Domainvalidierung
Alle Zahlen werden vollständig auf erlaubte Bereiche geprüft, bevor irgendein Ergebnis verändert wird: Quality 0 bis 120, Geschwindigkeit mindestens 0 sowie Brake und Drift jeweils 0 bis 1.

v2026-07-21-142329

Technische Zusammenfassung

Release 2026-07-21-142329 adressiert die Ursache der in Issue #10 gemeldeten Kameraunruhe. Das Issue bleibt bis zu Milos Realtest und Schließfreigabe offen; dieser Eintrag dokumentiert keine produktive Bereitstellung.

  • Root Cause: Das sichtbare Fahrzeug nutzte bereits die zwischen zwei Fixed Steps interpolierte Renderpose, während die Kamera noch direkt an der nicht interpolierten Physikpose ausgerichtet wurde. Bei unregelmäßiger Renderkadenz bewegten sich Fahrzeug und Kamera dadurch in unterschiedlichen zeitlichen Bezugssystemen.
  • Gemeinsame Renderpose: Fahrzeugmodell und Kamera leiten Position und Yaw nun aus derselben Fixed-Step-interpolierten Pose ab. Auch Kameraziel, Kollisionsziel und Distanz-Clamps sind an diese sichtbare Pose gebunden.
  • Reiner Geometrie-Helper: public/render/player-camera-pose.js kapselt die kürzeste Yaw-Interpolation und die Basisgeometrie der Kamera ohne Three.js- oder DOM-Abhängigkeit.
  • Deterministische Regressionen: Eine feste unregelmäßige Renderkadenz prüft die kohärente Basispose in allen vier Kameramodi; weitere Architekturtests sichern Interpolation, Frame-Reihenfolge, Helper-Einbindung, Clamps und Kamerakollision.
  • Verifikation: 320 Python- und 255 Node-Tests bestanden.
Einfach erklärt: Was wurde besser?

Das Auto wurde auf dem Bildschirm schon weich zwischen den einzelnen Berechnungsschritten bewegt. Die Kamera folgte dagegen noch den gröberen Sprüngen dieser Schritte. Wenn Bilder in wechselnden Zeitabständen gezeichnet wurden, konnten Auto und Kamera deshalb kurz gegeneinander versetzt wirken und das Bild unruhig erscheinen.

Jetzt verwenden das sichtbare Auto und die Kamera exakt dieselbe weich berechnete Position und Richtung. Das gilt für alle vier Kameraansichten und auch für die Punkte, mit denen Abstand und Hindernisse geprüft werden. Automatische Tests spielen dafür absichtlich eine feste Folge unterschiedlich langer Bildabstände ab. Issue #10 bleibt trotzdem offen, bis Milo das Fahrgefühl im echten Spiel geprüft und die Schließung freigegeben hat. Eine produktive Auslieferung wird hier nicht behauptet.

Fixed Step
Die Fahrphysik wird in gleich großen Zeitschritten berechnet, unabhängig davon, wie schnell oder unregelmäßig Bilder angezeigt werden.
Interpolierte Renderpose
Die für ein Bild weich berechnete Position und Richtung zwischen dem vorherigen und dem aktuellen Physikschritt.
Yaw-Interpolation auf dem kürzesten Bogen
Eine Richtungsänderung wird über den kürzeren Weg interpoliert, auch beim Übergang über die Grenze von plus zu minus 180 Grad.
Unregelmäßige Renderkadenz
Bilder werden in unterschiedlich langen Abständen gezeichnet. Die deterministische Prüfung verwendet dafür stets dieselbe vorgegebene Folge.
Kamera-Basispose, Kollisionsziel und Clamps
Basisposition und Blickziel der Kamera sowie der Bezugspunkt für Hindernisprüfungen und Begrenzungen. Sie folgen nun gemeinsam der sichtbaren Fahrzeugpose.

v2026-07-21-122530

Technische Zusammenfassung

Release 2026-07-21-122530 korrigiert für Issue #1 die Orientierung der fahrzeugzentrierten Minimap. Der Eintrag behauptet weder, dass das Issue geschlossen ist, noch eine Freigabe; Milos öffentliche Bestätigung bleibt das Gate.

  • Horizontale Welt→Canvas-Projektion: Das Vorzeichen der seitlichen, fahrzeugzentrierten Projektion ist jetzt an die tatsächliche Screen-right-Händigkeit der Three.js-Kamera angepasst.
  • Relative Fahrzeugmarkerrotation: Die gekoppelte Rotation anderer Fahrzeugmarker wird passend zur korrigierten horizontalen Projektion invertiert, sodass Position und sichtbare Ausrichtung dasselbe Bezugssystem verwenden.
  • Verhaltensbasierte Regressionen: Die Welt→Canvas-Projektion ist für vier Kardinal-Yaws des Spielerfahrzeugs abgedeckt; zusätzliche Fälle prüfen Fahrzeugmarker bei relativen Yaws von +90° und −90°.
  • Verifikation: 320 Python- und 249 Node-Tests bestanden.
Einfach erklärt: Was wurde besser?

Was rechts vom Auto sichtbar ist, liegt nun auch rechts auf der Minimap. Andere Fahrzeuge zeigen dort außerdem in dieselbe sichtbare Richtung wie in der Spielwelt. Die Position und die Spitze ihres Markers widersprechen sich dadurch nicht mehr.

Automatische Prüfungen drehen das eigene Auto in alle vier Hauptrichtungen und vergleichen die Kartenseite mit dem sichtbaren Kamerabild. Weitere Prüfungen stellen andere Fahrzeuge jeweils quer nach links und rechts. Milos öffentliche Bestätigung bleibt erforderlich; dieser Eintrag erklärt das Verhalten und meldet Issue #1 nicht als geschlossen oder freigegeben.

Fahrzeugzentrierte Welt→Canvas-Projektion
Die Position eines Objekts in der Spielwelt wird relativ zum eigenen Auto in eine Position auf der zweidimensionalen Minimap umgerechnet.
Three.js-Kamera-Screen-right-Händigkeit
Die tatsächliche Vorzeichenrichtung der Kameraachse, die im gerenderten Bild nach rechts zeigt. Die horizontale Minimap-Achse folgt nun genau dieser Richtung.
Relative Fahrzeugmarkerrotation
Die Markerspitze zeigt die Fahrtrichtung eines anderen Autos im Verhältnis zur Richtung des eigenen Autos. Ihre gekoppelte Rotation ist passend zur horizontalen Projektion invertiert.
Verhaltensbasierte Regressionen für Kardinal-Yaws und ±90°
Tests prüfen das sichtbare Ergebnis bei den vier Hauptrichtungen des eigenen Autos sowie bei um plus oder minus 90 Grad abweichenden Richtungen anderer Fahrzeuge, statt nur einzelne Quelltextzeichen zu kontrollieren.

v2026-07-21-091905

Technische Zusammenfassung

Dieses immutable Release ist deploy-bereit, dokumentiert aber keine produktive Bereitstellung. Seit 2026-07-20-090723 vervollständigt es den builderseitigen Encoded-LOD-Catalog-Vertrag und korrigiert die Koordinatenprojektion.

  • Source-Bindung: Der Verifier revalidiert das kanonische source-only Verified Artifact Package und bindet den kanonischen Katalog daran sowie an den exakten SHA-256-Digest seiner manifest.json.
  • Vollständigkeits- und Pfadvertrag: Pro Source-Tile sind exakt HERO, NEAR, MID und FAR erforderlich. Assetpfade müssen sicher, eindeutig, lexikografisch sortiert und segment-präfixfrei sein; Transform, lokale Bounds und Placement werden gegen den Source-Vertrag geprüft.
  • Fail-fast und immutable Ausgabe: Eine harte frühe 64-MiB-Grenze, exakt viermal so viele Assets wie Source-Tiles und die Schemaprüfung stoppen ungültige Kataloge vor Kopieren und Parsen. Externe Validierungsfehler werden stabil als TileBuildError normalisiert; der Rückgabewert ist ein input-entkoppelter immutable Snapshot.
  • Korrigierte Projektion: Python-Placement sowie JavaScript-Placement und Runtime-Bounds sind jetzt einheitlich relativ zum Game-Origin berechnet; der projizierte Grid-Origin wird nicht mehr doppelt addiert.
  • Bewusst nicht enthalten: Keine Meshopt-/KTX2-Erzeugung, keine Asset-Existenz- oder Codec-Binärprüfung, keine Full-AOI-Produktion und keine Runtime-Integration komprimierter Assets.
  • Verifikation: 320 Python- und 243 Node-Tests bestanden.
Einfach erklärt: Was wurde besser?

Der Builder prüft jetzt streng eine Inhaltsliste für vorbereitete Detaildateien. Jede Kartenkachel braucht genau vier Detailstufen. Dateinamen müssen sicher, eindeutig und in einer festen Reihenfolge angegeben sein, und die Liste muss exakt zu den erneut geprüften Quelldaten passen. Zu große oder offensichtlich unvollständige Listen werden beendet, bevor unnötige Arbeit beginnt. Das Prüfergebnis ist danach eine eigene unveränderliche Kopie, die spätere Eingabeänderungen nicht verfälschen können.

Python und JavaScript setzen Kartenkacheln nun vom selben Spiel-Nullpunkt aus ein. Position und sichtbare Grenzen werden dadurch nicht mehr versehentlich doppelt um den Kartenraster-Ursprung verschoben. Das Release ist für ein Deployment vorbereitet, aber nicht als produktiv ausgerollt behauptet. Es erzeugt noch keine komprimierten Dateien, prüft weder deren Vorhandensein noch binären Inhalt, baut nicht das gesamte Zielgebiet und lädt solche Dateien noch nicht ins Spiel.

Encoded-LOD-Catalog
Eine maschinenlesbare Inhaltsliste der vier Detaildateien HERO, NEAR, MID und FAR für jedes Source-Tile.
Revalidiertes Source-Artifact-Package und Manifest-Digest
Das Quellpaket wird erneut vollständig geprüft; zusätzlich muss die SHA-256-Prüfsumme exakt zu seinen kanonischen manifest.json-Bytes passen.
Segment-präfixfreier Assetpfad
Kein vollständiger Pfad darf am Segmentrand der Anfang eines anderen sein. Zusammen mit sicheren, eindeutigen und sortierten Pfaden verhindert das mehrdeutige Dateizuordnungen.
Transform, Bounds und Placement
Transform ist die Koordinatenabbildung, Bounds sind die lokalen räumlichen Grenzen und Placement ist die Position einer Kachel relativ zum Game-Origin.
Fail-fast, 64-MiB-Grenze und exakte Assetzahl
Fehlerhafte, zu große oder bereits anhand ihrer Anzahl unvollständige Kataloge werden vor unnötigem Kopieren, Parsen und weiteren Prüfungen beendet.
Stabile TileBuildError-Normalisierung
Unterschiedliche Fehler der externen Schemaprüfung erscheinen als ein vorhersehbarer Builder-Fehlertyp mit stabiler Meldung.
Immutable, input-entkoppelter Snapshot
Das verifizierte Ergebnis ist unveränderlich und teilt keine veränderlichen Daten mit der Eingabe.

v2026-07-20-090723

Technische Zusammenfassung

Dieser deploy-bereite Git-Zwischenstand schließt die Härtung aus Issue #17 ab und ergänzt für Issue #13 ein source-only Verified Artifact Package. Er dokumentiert einen geprüften Quellstand, aber keine produktive Bereitstellung.

  • Cleanup-Vault und Crash-Durability (#17): Ein persistenter Vault mit Modus 0700 und .guard kapselt Stage-/Backup-Cleanup. Identity-bound Nofollow-Prüfungen, Directory fsync und eine explizite Commit-Grenze sichern die Wiederaufnahme nach Abstürzen.
  • Begrenzte Trust-Annahme (#17): Cleanup löscht keine fremden Objekte, erhält die ursprünglichen Exceptions stabil und setzt ausdrücklich voraus, dass Prozesse derselben effektiven Benutzerkennung (Same EUID) vertrauenswürdig sind.
  • Verified Artifact Package (#13, Zwischenstand): artifact-package.json ist kanonisch und schema-versioniert, erfasst Content-Hashes, Größen, Rollen und echte JSON-Codecs und verlangt eine exakte Bijektion zwischen Manifest, Coverage und Tiles.
  • Reproduzierbarer Package-Vertrag: Unterstützte CRS-, Grid- und Tool-Versionen, Pre-copy-Budgets, ein unveränderlicher Verifier sowie snapshot-gebundene atomare Publikation schließen uneindeutige oder während der Prüfung veränderte Quellen aus.
  • Bewusst nicht enthalten: Dieser source-only Zwischenstand enthält keine Meshopt-, Draco- oder KTX2-Kompression und keine Runtime-Integration.
  • Verifikation: Der finale Git-Stand besteht 282 Python- und 243 Node-Tests.
Einfach erklärt: Was wurde besser?

Der World-Builder bewahrt angefangene Aufräumarbeiten jetzt in einem dauerhaft geschützten Verzeichnis auf. Nach einem Abbruch erkennt er seine eigenen Zwischenstände wieder, folgt dabei keinen symbolischen Verknüpfungen und entfernt nichts, das nicht eindeutig zu diesem Vorgang gehört. Verzeichnisänderungen werden zusätzlich so synchronisiert, dass ein Stromausfall keinen nur halb veröffentlichten Stand hinterlassen soll.

Außerdem kann der Builder zu seinen Quelldateien nun eine maschinenprüfbare Paketbeschreibung ausgeben. Sie zählt alle erwarteten Kacheln genau einmal auf, hält Prüfsummen und Größen fest und bindet die Prüfung an denselben unveränderten Snapshot. Das ist eine abgesicherte Quelle für spätere Verarbeitung, noch kein komprimiertes oder im Spiel geladenes Runtime-Paket.

Persistenter Cleanup-Vault (0700) mit .guard
Ein dauerhaftes Aufräumverzeichnis, auf das nur sein Besitzer zugreifen darf; die Guard-Datei kennzeichnet die erwartete Vault-Identität.
Identity-bound Nofollow Stage-/Backup-Cleanup
Aufräumen ist an das zuvor geprüfte Dateiobjekt gebunden und folgt keinen symbolischen Links. Ausgetauschte oder fremde Stage-/Backup-Objekte bleiben unangetastet.
Same-EUID Trust-Annahme
Das Schutzmodell nimmt ausdrücklich an, dass kein nicht vertrauenswürdiger Prozess mit derselben effektiven Benutzerkennung den Vault manipuliert.
Directory fsync und stabile Original-Exception
Geänderte Verzeichniseinträge werden dauerhaft synchronisiert. Scheitert danach zusätzlich das Aufräumen, bleibt dennoch der ursprüngliche Fehler als maßgebliche Exception erhalten.
Kanonisches, schema-versioniertes artifact-package.json
Eine eindeutig serialisierte JSON-Inhaltsliste mit Vertragsversion, Rollen, echten JSON-Codec-Angaben, Dateigrößen und Content-Hashes.
Manifest-/Coverage-/Tile-Bijektion
Jeder erwartete Rasterplatz besitzt genau ein passendes Tile und jeder aufgeführte Tile gehört genau zu einem erwarteten Rasterplatz.
CRS-/Grid-/Tool-Vertrag und Pre-copy-Budgets
Koordinatensystem, Raster und Werkzeugversion müssen unterstützt sein; Anzahl und Gesamtgröße werden begrenzt, bevor Dateien kopiert werden.
Immutable Verifier und snapshot-gebundene atomare Publikation
Die Prüfung arbeitet gegen denselben unveränderten Quelldatenstand. Sichtbar wird entweder das vollständige geprüfte Paket oder weiterhin der vorherige Stand.

v2026-07-20-000944

Technische Zusammenfassung

Issue #17 härtet die Veröffentlichung von World-Tiles gegen Wettläufe und Prozessabstürze: Der Builder veröffentlicht nur vollständig vorbereitete Ergebnisse und kann unterbrochene eigene Transaktionen sicher wiederaufnehmen, ohne fremde Pfade zu löschen.

  • Persistenter, fd-verankerter Cleanup-Vault: Der Vault mit Modus 0700 und eine Guard-Datei mit 0600 binden Cleanup-Ziele an eine kontrollierte Identität.
  • Race-sichere Pfadoperationen: Nofollow-/Identity-/No-replace-Prüfungen verhindern Symlink-Folgen, Objektverwechslungen und unbeabsichtigtes Überschreiben.
  • Recovery statt fremder Löschung: Abgebrochene eigene Publikationen werden aus dem Vault rekonstruiert; nicht eindeutig zuordenbare oder fremde Einträge bleiben unangetastet.
  • Crash-Durability: Eine explizite Commit-Grenze (Commit Boundary) und Bottom-up Directory fsync machen sowohl veröffentlichte Daten als auch die dazugehörigen Namespace-Änderungen dauerhaft.
  • Nonblocking Special-file Rejection und Trust-Grenze: Spezialdateien werden nichtblockierend abgelehnt. Der Vault schützt nicht gegen untrusted Same-EUID-/Root-Prozesse; diese Akteure liegen ausdrücklich außerhalb der Trust-Grenze.
Einfach erklärt: Was wurde besser?

Beim Erzeugen neuer Weltkacheln kann das Programm jetzt auch dann sauber weiterarbeiten, wenn zwei Abläufe gleichzeitig aktiv sind oder der Rechner genau beim Speichern ausfällt. Spieler erhalten entweder den letzten vollständigen Stand oder den vollständig fertigen neuen Stand – keinen halbfertigen Mischzustand.

Aufräumarbeiten betreffen nur Dateien, die der Builder eindeutig als seine eigenen erkennt. Verdächtige Verknüpfungen, ausgetauschte Dateien und ungewöhnliche Dateitypen werden nicht geöffnet oder entfernt. Nach einem Abbruch wird der eigene angefangene Vorgang wiedergefunden und kontrolliert abgeschlossen oder bereinigt.

Cleanup-Vault (0700) und Guard (0600)
Ein dauerhaftes, nur für den Besitzer zugängliches Aufräumverzeichnis und seine nur für den Besitzer les- und schreibbare Kennungsdatei. Ein offener Verzeichnisdeskriptor verankert Operationen am geprüften Verzeichnisobjekt statt nur an dessen Namen.
Nofollow, Identitätsprüfung und No-replace
Operationen folgen keinen symbolischen Links, prüfen das konkrete Dateiobjekt erneut und ersetzen beim Umbenennen kein bereits vorhandenes Ziel.
Commit-Grenze und Bottom-up Directory fsync
Die Commit-Grenze markiert den verbindlichen Veröffentlichungszeitpunkt. Danach werden geänderte Verzeichnisse von innen nach außen synchronisiert, damit ihre Einträge einen Absturz überstehen.
Nichtblockierende Spezialdatei-Ablehnung
Pipes, Geräte und andere unerwartete Dateitypen werden so geprüft und abgelehnt, dass der Builder dabei nicht auf Eingaben warten kann.
Trust-Grenze
Das Schutzmodell setzt voraus, dass kein nicht vertrauenswürdiger Prozess mit derselben effektiven Benutzerkennung und kein Root-Prozess den Vault manipuliert.

v2026-07-19-220520

Professionelle Zusammenfassung

Dieser World-Tile-Slice macht die AOI-Rasterung vollständig, deterministisch und transaktional: Alle tatsächlich von der AOI belegten Zellen werden geplant, während ungültige oder übergroße Eingaben vor Geometrieverarbeitung und Ausgabe ohne beobachtbare Nebenwirkungen scheitern.

  • Vollständige AOI-Grid-Coverage: Jede Rasterzelle mit positiver Flächenschnittmenge zur AOI wird deterministisch ausgegeben – ausdrücklich auch eine Zelle ohne Straßen, Gebäude oder andere Quelldatensätze.
  • Präzises Flächenkriterium: Reine Kanten- oder Punktberührungen erzeugen keine Tiles; nur eine Schnittmenge mit positiver Fläche zählt zur Coverage.
  • Atomare Budgets: Kandidatenprüfungen und die vereinigte Outputmenge werden vollständig vorab gezählt und gemeinsam begrenzt, bevor Tile-Dokumente entstehen.
  • Fail-closed Preflight: Raw-JSON-Struktur und -Komplexität sowie GeoJSON- und LoD2-Struktur, Gesamt- und Pro-Objekt-Komplexität werden vor Shapely/GEOS und vor jeder Output-Serialisierung validiert.
  • Side-effect-freie Fehler: Semantische Validierungsfehler verändern weder eine vorhandene Ausgabe noch erzeugen sie Staging-Verzeichnisse oder teilweise Artefakte.
Einfach erklärt: Was wurde besser?

Der Builder teilt den ausgewählten Kartenausschnitt in gleich große Kacheln. Jetzt wird jede Kachel erzeugt, die wirklich einen Teil dieser Fläche abdeckt – auch wenn darin gerade keine Straße und kein Gebäude liegt. Berührt der Ausschnitt eine Kachel nur an einer Linie oder an einem Punkt, zählt sie dagegen nicht.

Bevor aufwendige Geometrie berechnet oder etwas auf die Festplatte geschrieben wird, prüft der Builder die vollständige Eingabe und zählt den geplanten Arbeitsumfang. Sind Daten fehlerhaft oder zu groß, stoppt er kontrolliert und lässt eine vorhandene Ausgabe unverändert.

AOI-Grid-Coverage
Die vollständige Menge aller Rasterzellen, die einen echten Flächenanteil des ausgewählten Kartenausschnitts (Area of Interest) enthalten.
Positive Flächenschnittmenge
AOI und Rasterzelle überlappen sich auf einer messbaren Fläche; eine bloße Berührung an Rand oder Ecke genügt nicht.
Atomare Kandidaten-/Outputbudgets
Grenzen für geprüfte Rasterpositionen und erzeugte Tiles werden vor der Verarbeitung als Ganzes ausgewertet. Eine Überschreitung hinterlässt kein Teilergebnis.
Raw-JSON-, GeoJSON- und LoD2-Preflight
Eine vorgeschaltete Prüfung begrenzt Verschachtelung, Struktur, Datensatz- und Koordinatenmengen der Rohdaten sowie der Karten- und Gebäudeflächen, bevor Shapely/GEOS Geometrien konstruiert.
Fail-closed
Unklare, ungültige oder übergroße Eingaben werden abgelehnt, statt stillschweigend vereinfacht oder teilweise verarbeitet zu werden.
Side-effect-freier semantischer Fehler
Ein inhaltlicher Eingabefehler beendet den Build, ohne Output zu serialisieren, Verzeichnisse anzulegen oder den letzten gültigen Stand zu verändern.

v2026-07-19-192426

Professionelle Zusammenfassung

Dieser AOI-Geometrie- und Validierungsslice verschärft den World-Intermediate-Vertrag: Die projizierte AOI-Geometrie bleibt verpflichtend in kanonischer Form erhalten und wird am Vertrauensrand des Builders fail-closed geprüft.

  • Kanonischer World-Intermediate: Das strukturell geschlossene Schema verlangt die projizierte AOI als Polygon oder MultiPolygon, statt sie nach der Quellenverarbeitung zu verlieren.
  • XML/PBF-Parität: Beide OSM-Eingabeformate erzeugen dieselbe kanonische AOI-Repräsentation.
  • Topologische Validierung: Der Builder akzeptiert nur geschlossene Ringe mit endlichen Koordinaten, gültiger Polygon-/MultiPolygon-Topologie und positiver Fläche.
  • Begrenzter Umfang: Adversariale Regressionstests sichern diesen Slice ab; Issue #13 bleibt insgesamt offen.
Einfach erklärt: Was wurde besser?

Der für einen Welt-Build ausgewählte Kartenausschnitt wird jetzt als echte, projizierte Fläche durch die Verarbeitung weitergereicht. XML- und PBF-Quellen werden dabei gleich behandelt. Ist diese Fläche unvollständig oder geometrisch ungültig, bricht der Builder kontrolliert ab, statt mit zweifelhaften Grenzen weiterzubauen.

AOI (Area of Interest)
Der räumlich festgelegte Ausschnitt, für den Weltdaten verarbeitet werden.
Projizierte Geometrie
Die AOI in einem metrischen Koordinatensystem, dargestellt als Polygon oder MultiPolygon.
Topologie
Die strukturellen Beziehungen einer Fläche: Ringe müssen geschlossen sein, Polygone gültig zusammengesetzt und ihre Flächen positiv sein.
Fail-closed
Unendliche oder nicht numerische Werte sowie ungültige Flächen werden am Builder-Vertrauensrand abgelehnt; es gibt keinen stillen Fallback.

v2026-07-19-084726

Professionelle Zusammenfassung

Dieses Infrastruktur-Update definiert einen strikten, prüfbaren Vertrag für kommende Berlin-Tiles mit vier echten Detailstufen und eindeutiger Koordinatenabbildung.

  • LOD-Catalog: Pro Tile sind exakt vier eindeutig adressierte und integritätsgebundene Assets vorgeschrieben.
  • Koordinaten-Transform: EPSG:25833, Tile-Ursprung und Höhenversatz werden explizit in lokale Spielkoordinaten überführt.
  • Fail-closed Product Path: Produktdaten benötigen passende Schema-Versionen, SHA-256-Bindung und sichere Größenmetriken; Legacy-Daten bleiben ein ausdrücklich separater Entwicklungspfad.
Einfach erklärt: Was wurde besser?

Die nächste Ausbaustufe der Stadt kann Tiles nicht mehr versehentlich mit falscher Position, falscher Höhe oder unpassenden Detaildateien laden. Fehlerhafte Pakete werden abgelehnt, bevor sie dargestellt werden.

Technische Details und Regressionen
  • Manifest-Schema 2.0 und Encoded-LOD-Catalog 1.0 verlangen exakt LOD 0–3, sichere relative Pfade, lowercase SHA-256 und endliche Safe-Integer-Metriken.
  • projected_to_game bindet CRS, Meter-Einheiten, Achsenmatrix, horizontalen Ursprung und vertical_origin.
  • Der Catalog wird gegen den verifizierten Source-Manifest-Digest gebunden; falsche Versionen oder Koordinatensysteme werden ohne stillen Fallback verworfen.

v2026-07-19-081455

Professionelle Zusammenfassung

Dieses World-Streaming-Update härtet die Gebäude-Occlusion gegen falsches Ausblenden und begrenzt die prädiktive Route auf die unmittelbar kommenden Streckenpunkte.

  • Konservative Occlusion: Nur eine garantiert innerhalb der projizierten Gebäudehülle liegende Fläche darf andere Chunks verdecken.
  • Near-Plane-Sicherheit: Gebäude, die die Kamera-Nahgrenze berühren oder schneiden, werden nicht als Occluder verwendet.
  • Route-Look-ahead: Der Streamer priorisiert einen endlichen Korridor entlang der kommenden Rennroute statt die gesamte Route anzufordern.
Einfach erklärt: Was wurde besser?

Gebäude am Bildrand oder direkt vor der Kamera verschwinden nicht mehr fälschlich, nur weil ihre grobe Bildschirmbox ein anderes Gebäude überlappt. Gleichzeitig lädt das Spiel gezielter in Fahrtrichtung voraus.

Technische Details und Regressionen
  • Die konvexe Projektion eines AABB liefert für Kandidaten die äußere Begrenzung, für solide Occluder jedoch ein durch alle Hull-Halbräume begrenztes inneres Rechteck.
  • Clip-Space-Prüfungen verwerfen Occluder fail-open, sobald eine Ecke w <= epsilon oder clipZ < -w + epsilon erfüllt.
  • Adversariale Off-axis-, Near-plane- und rotierte Kamera-Fälle sind als Regressionstests abgedeckt.

v2026-07-18-230302

Professionelle Zusammenfassung

Dieses Stabilitäts- und Bedienungsupdate trennt Fahrsteuerung zuverlässig von Menüs, Formularen und modalen Dialogen und vereinheitlicht den Abschluss lokaler und vernetzter Rennen.

  • Eingabe-Routing: Tastaturbefehle greifen nicht mehr in Textfelder, Regler, Buttons, Links oder aufklappbare Release-Details ein.
  • Controller-Fallback: Ein neutraler angeschlossener Gamepad-Stick überschreibt aktive Tastatur- oder Touch-Lenkung nicht mehr; Touch-Lenkung wird nach einer Controller-Auslenkung deterministisch wiederhergestellt.
  • Modaler Changelog: Das Spiel pausiert beim Lesen, Escape schließt nativ, ein zuvor pausiertes Spiel bleibt anschließend pausiert und eingehende Online-Rennstarts heben die modale Pause nicht auf.
  • Multiplayer-Ziel: Lokale, entfernte und beim Raumbeitritt synchronisierte Resultate verwenden dieselbe Abschlussprüfung; getrennte oder beim Senden als veraltet erkannte Starter werden autoritativ entfernt und allen verbleibenden Clients gemeldet.
Einfach erklärt: Was wurde besser?

Du kannst jetzt Namen, Passwörter und Räume eingeben oder Einstellungen bedienen, ohne dabei versehentlich zu lenken, die Kamera zu wechseln oder das Spiel zu pausieren. Der Changelog hält das Rennen an, solange du liest. Außerdem endet ein Online-Rennen nun auch dann korrekt, wenn der letzte Mitspieler nach dir ins Ziel kommt.

Technische Details und Regressionen
  • Interaktive Event-Ziele und offene Dialoge werden vor globalem Gameplay-Keyhandling gefiltert; Keyup räumt gehaltene Zustände weiterhin sicher auf.
  • Gamepad-Lenkung übernimmt den Zielwert nur außerhalb der Deadzone; modale Dialoge blockieren Gamepad-Pause und Kamerawechsel.
  • Der Changelog merkt sich den vorherigen Pausezustand und setzt ihn beim Schließen ohne unbeabsichtigtes Auto-Resume zurück.
  • maybeFinishRace() wird nach lokalen, entfernten und hydrierten Ergebnissen ausgeführt.

v2026-07-18-215146

Professionelle Zusammenfassung

Die Release Notes dokumentieren den aktuellen World-Streaming-Checkpoint jetzt in drei Informationsebenen: kompakte Systemzusammenfassung, verständliche Wirkungserklärung und präzise Implementierungsdetails.

  • Streaming-Architektur: deterministischer, budgetierter Tile-Lifecycle mit prädiktiver Nachfrage, Cancellation, Cache-Eviction und expliziter Ressourcenübergabe.
  • Sichtbarkeit und Detail: Frustum-, Distanz-, Projektionsgrößen- und konservative Occlusion-Auswertung steuern vier Gebäude-LODs mit Hysterese.
  • Runtime-Integration: Berliner Gebäudegeometrie wird in unabhängigen Chunks geladen; pro Chunk bleibt genau die feinste verfügbare Stufe sichtbar.
  • Belastbarkeit: harte Fetch-, Decode-, Upload-, CPU- und GPU-Budgets sowie ein deterministischer Zehn-Minuten-Soak decken Lifecycle- und Speichergrenzen ab.
Einfach erklärt: Was bringt mir das?

Die Stadt wird nicht mehr komplett auf einmal vorbereitet. Das Spiel kümmert sich zuerst um das, was du gerade siehst oder gleich erreichen wirst. Dadurch bleiben Ladezeit und Speicherverbrauch kontrollierbar.

Frustum Culling
Die Kamera sieht nur einen räumlichen Ausschnitt. Gebäude hinter dir oder weit außerhalb des Bildes müssen deshalb gerade nicht gezeichnet werden.
Level of Detail (LOD)
Weit entfernte Gebäude werden vereinfacht dargestellt. Beim Näherkommen ersetzt das Spiel sie schrittweise durch genauere Modelle. Das spart Leistung, ohne die Nähe sichtbar grob zu machen.
Hysterese
An einer Entfernungsgrenze wird nicht bei jedem kleinen Kamerawackler zwischen zwei Detailstufen hin- und hergeschaltet. Ein kleiner Puffer verhindert sichtbares Flackern.
Predictive Streaming
Das Spiel lädt nicht nur deinen aktuellen Bereich, sondern begrenzt auch Bereiche in Fahrtrichtung und entlang der nächsten Routenpunkte vor. So soll benötigte Geometrie rechtzeitig bereitstehen.
Occlusion Culling
Ein vollständig verdecktes Gebäude muss nicht gezeichnet werden. Die Prüfung ist absichtlich vorsichtig: Im Zweifel bleibt das Gebäude sichtbar, statt versehentlich zu verschwinden.
Soak-Test
Eine lange, reproduzierbare Testfahrt simuliert zehn Minuten ständiges Laden und Entladen. Dabei wird geprüft, ob Speicher, Warteschlangen und Ressourcen auch unter dauerhaftem Wechsel begrenzt bleiben.
Technische Details und Fachbegriffe
  • Spatial manifest: kanonische Tile-IDs, sichere relative Asset-Pfade, SHA-256-Metadaten, halb offene AABB-Abfragen und deterministische Sortierung.
  • Visibility policy: Frustum Culling, projected screen-size thresholds, vier direkte LOD-Bänder (FAR/MID/NEAR/HERO), Hysterese und fail-closed Occlusion-Inputs.
  • Predictive Streaming: bounded velocity corridor und finite route horizon; pollbare Fetch-/Decode-/Upload-Jobs mit Generation Tokens und stale-completion disposal.
  • Resource ownership: Vorab-Reservationen, explizite Ownership-Transfers, deterministische LRU-Eviction, Cancellation-Drain und exception-sichere Disposal-Pfade.
  • Runtime bridge: kryptografisch gebundene Payloads, one-finest-resident selection und chunkweise Three.js-BufferGeometry mit deterministischem GPU-Dispose.
  • Verification: adversariale Lifecycle-Tests und 36.000 deterministische Frames mit unabhängigen CPU-/GPU-Ownership-Ledgern.

v2026-07-18-213346

  • World streaming: added a deterministic spatial tile manifest with strict schema, integrity metadata and bounded spatial queries.
  • Visibility and LOD: added frustum, distance and projected-size culling, four direct building LOD bands and hysteresis to stop rapid LOD switching.
  • Predictive loading: streams the current tile, velocity corridor and a finite route horizon while enforcing fetch, decode, upload and memory budgets.
  • Runtime buildings: moved Berlin building geometry into independently streamed chunks with FAR, MID, NEAR and HERO geometry plus one-finest-resident fallback.
  • Resource safety: added explicit ownership transfer, cancellation, stale-job disposal, deterministic eviction and teardown accounting.
  • Occlusion: added projected building occlusion candidates, solid rectangular footprint filtering and live candidate/culled diagnostics.
  • Route look-ahead: race routes are limited to six finite points and open-world road look-ahead to four points.
  • Reliability: added a deterministic ten-minute-equivalent streamer soak test; the current suite covers bounded memory and lifecycle behavior.

v2026-07-18-212725

  • Added the clickable in-game changelog dialog with backdrop, close button and Escape support.

v2026-07-18-212253

  • Corrected release metadata so the HUD, Dockge image and Kubernetes manifest report the same build.

v2026-07-18-196

  • Added the PBR night/rain pipeline, wet-road response, SSR, planar reflections, bloom, color grading and FXAA.
  • Added immutable graphics quality tiers, capability-based fallbacks and independent effect controls.
  • Added pooled rain, splash, mist and city-light systems with bounded render resources.

v2026-07-17-196

  • Added the PBR night/rain pipeline, wet reflections and graphics quality controls.
  • Added procedural Berlin facade materials and deterministic world data.
  • Expanded force-based vehicle dynamics, drivetrain and drift modes.