# Bug-Report: Absturz beim Laden eines Spielstands — LoadTableFile:233

- Typ: bug
- Datum: 2026-09-27 (Crash-Log vom 2026-09-12)
- Session: tlsid7jyrdw9mujokxbp (Bug-Chat, manuell analysiert)
- Version: ~0.4.1.x
- Melder-Notiz: „passiert beim starten eines neuen spiels" — das Log zeigt aber
  `Loading Stage : LoadGame`, d. h. es war ein Save-Laden, kein New Game.

## Zusammenfassung
Der Save-Lade-Thread stirbt in `LoadTableFile.ExtractVar` (Z. ~233), weil die
serialisierte Datei einen Typ-Tag `t` enthält, den der Parser nicht kennt
(nur `S`/`N`/`B`/`T`/`TE` werden akzeptiert). Datei:
`Save/Aether Point Zeta/Autosave_2026-09-12-21-53-35//Asteroids/IronCore - 104511319/MapData.tbl`.

## Fehler
```
Error: Thread error (Thread: 0x038ad380)
Libraries/SaveLoad/LoadTableFile.lua:233: ... Wrong formatet Variable t in
  t T S 1 x N 0 S 1 y N 0 TE S 4 Type S 10 EnergyCell ...
Libraries/Threads/CreateUpdateThread.lua:64: in main chunk
```

## Technische Analyse
Der Value-Buffer-Dump zeigt, dass der Parser mitten in der `Inventory`-Tabelle
eines LaserTowers war (`EnergyCell`, `UsedBattery`, `ItemFilter`,
`RenderVersion` …), als er auf `t` traf. Der aktuelle Serializer
(`SaveTableFile.lua`) emittiert ausschließlich `N`/`S`/`B`/`T`/`TE` —
kein `t`. `git log -S'"t "'` findet nur den Initial-Commit, d. h. der Tag war
nie Teil des Formats bzw. wurde nie entfernt.

Wahrscheinlichste Ursache: korrupte Autosave-Datei — Asteroiden werden über
Save-Threads geschrieben (`ThreadManager`/`SaveTargetThread`); ein
abgebrochener Schreibvorgang (Absturz/Quit während Autosave) hinterlässt
eine teilgeschriebene Datei. Auffällig: `AttackCoolDown = -179539.94` im
Dump — deutet auf unsaubere/alte Daten hin.

Fix-Richtung:
- Als korrupten Spielstand behandeln: sauberer „Spielstand beschädigt,
  kann nicht geladen werden"-Fehler statt Thread-Kill — der `error()`-
  Aufruf wandert durch den Thread und löscht nur `t`.
- Optional: `VerifySave`-Pre-Flight beim Laden, oder Autosave-Schreiben
  atomar machen (Temp-Datei + Rename), damit abgebrochene Saves gar nicht
  entstehen.
- `AssertContract`-Pfad bleibt laut (Kais Regel), aber der Nutzer sollte
  einen lesbaren Fehler bekommen.