Aber es gibt auch eine Möglichkeit, die richtige Spieldauer einzutragen, weil der Spielstream in das Replay nach ersten Erkenntnissen konstant ist, d.h. pro Zeit-Intervall immer eine bestimmte Anzahl an Bits speichert. Das heißt man kann theoretisch aus der Größe und Spieleranzahl (vllt. auch Mapgröße ? - ka) die Spiellänge errechnen. Dazu sind wohl noch ein paar Tests nötig, was aber ein wenig Zeit beansprucht und momentan sind ja alle bekanntlich etwas im Stress wegen Uni und Weihnachten usw.
Dies ist so leider nicht ganz korrekt, Replays bestehen im Grunde aus einem sechs Teilen.
Einem Formatstempel, einem ASCII Informationsteil, Konfigurationsinformationen (inkl. Spielernamen etc.), einem Preloadanteil, einer zyklischen Auflistung des Inputs während des Spiels und einem Footer.
Bei einer Beschädigung des Replays wird der Input unterbrochen, womit ein Replay nicht abgeschlossen werden kann, was im schlimmsten Fall bedeutet, dass der letzte Zyklus unvollständig beschrieben wurde und der Footer fehlt.
Jedoch ist der Inhalt jedes Zyklus unterschiedlich groß, je nachdem ob VOIP aktiviert wurde ( oder sogar ein AC exisitiert ) und wie viele Spieler / Aktionen auftraten etc.
Man muss somit die Grenzen eines jeden Zyklus beachten.
Ferner muss man daher auch nur den letzten abgeschlossenen Zyklus betrachten, dort sieht man schon sehr eindeutig, wie man den letzten beenden kann. Für den Input kann man einfache Dump-Werte einsetzen und spezielle Rasterbytes kann man anhand des vorherigen Zyklus korrekt fortsetzen.
Wenn man nun noch einen Footer einfügt ist alles in Ordnung. Wenn man nun noch die Anzahl der Datenströme zählen würde kann man auch sehr leicht eine Abschätzung der Replaydauer gewährleisten.
CnC3:TW-Replays sind ja eher primitive Datenformate, die einzige Schwierigkeit liegt eher darin, dass sie nicht dokumentiert sind.