Spielstände
Ein eingehängter Spielstand-Slot wird zu einem beschreibbaren /savedata0. Der Titel nutzt die gewöhnliche Datei-API, und der nächste Start findet dieselben Dateien unter dem Produktcode, den der Titel bekannt gibt.
Repository-Notizen bis 10. Oktober 2026
Wo ein Spielstand liegt
Die Installation des Spiels ist nur lesbar, kann auf Wechselmedien liegen und wird beim Patchen als Ganzes ersetzt. Ein Spielstand muss alle drei überdauern. PS5PCEM legt Slots unter savedata/<titleId>/<slot>/ im Home des Emulators ab, geschlüsselt nach dem Produktcode, den der Titel meldet. Zwei Dumps desselben Spiels teilen sich die Spielstände. Zwei verschiedene Spiele tun das nicht.
Der Slotname kommt vom Gast und wird bereinigt, bevor er ein Verzeichnis wird. Trenner, der Doppelpunkt des Laufwerks und Verweise auf das Elternverzeichnis werden zu Unterstrichen. Diese Zeichen zu streichen würde zwei verschiedene Namen auf ein Verzeichnis zusammenfallen lassen. Ein Name, der überhaupt kein Verzeichnis sein kann, fällt auf einen festen Namen zurück, weil es schlimmer ist, den Spielstand zu verlieren, als ihn an einen vorhersehbaren Ort zu legen.
Einhängen und Existenzprüfungen
Ein Mount löst den Slot auf und richtet /savedata0 darauf. Ein fehlender Slot wird nur angelegt, wenn der Titel einen verlangt hat. Eine Anfrage nach einem Spielstand, den der Titel nie geschrieben hat, erhält ein Ergebnis für fehlend, und genau das erwartet der Titel. Alles, was mit dem Titel ausgeliefert wurde, bleibt nur lesbar. Der Mount für Spielstände ist der beschreibbare Ort.
Die Existenz wird über den Metadatenpfad beantwortet, nicht durch Öffnen der Datei. Ein Mount, der erst beim Öffnen Erfolg hatte, ließ jede Existenzprüfung fehlschlagen, und Jets 'n' Guns 2 schrieb sein Profil deshalb bei jedem Start neu. Auch das Auflisten der Slots, die ein Titel geschrieben hat, wird beantwortet. Der Mount meldet außerdem, ob er einen vorhandenen Spielstand geöffnet oder einen neuen angelegt hat. Die blockförmige Spielstand-API nutzt einen getrennten Blob je Titel unter sce_sdmemory, geladen, wenn der Titel ihn reserviert, und geschrieben, wenn der Titel eine Synchronisation verlangt.
Unvollständige Slots
Die Suche beim Start verbirgt unterbrochene Slots, die nur Firmware-Metadaten oder leere Bereitstellungsdateien enthalten. Cat Quest III hatte einen nachgestellten Einstellungs-Slot, der nur path.txt enthielt. Der Titel scheiterte danach an einer fehlenden Data.dat und wartete nach seinem Startbild endlos. Die Suche überspringt diesen unvollständigen Slot jetzt und macht weiter.
Der Launcher gruppiert auf der Seite Spielstände jeden lokalen Slot nach der Titel-ID, einschließlich Spielständen, die eine andere Kachel der Bibliothek geschrieben hat. Ein Entwicklungsbuild unter zig-out löst das Home des Emulators auf die Wurzel des Repositorys auf. Ein gepackter Build nutzt sein eigenes Verzeichnis. Starts desselben Pakets von der Kommandozeile und aus dem Launcher teilen sich daher eine Spielstand-Wurzel.
Was umgesetzt ist
- Beschreibbare Mounts von /savedata0, geschlüsselt nach der Titel-ID, mit bereinigten Slotnamen.
- Existenzprüfungen, das Auflisten von Slots und eine Meldung, ob der Mount den Spielstand angelegt hat.
- Ein Blob je Titel unter sce_sdmemory für die blockförmige Spielstand-API.
- Verbergen unterbrochener Slots, die keine echte Spielstand-Nutzlast enthalten.
Was noch fehlt
- Spielstände sind Verzeichnisse des Hosts. Der Spielstand-Dialog der Konsole und die Cloud-Synchronisation werden nicht dargestellt.
- Ein Slot, den der Titel nicht anlegen lassen wollte, wird als fehlend gemeldet.
- Trophäen, Aktivitäten und andere an ein Konto gebundene Datensätze liegen außerhalb dieses Mounts.
Verwandte Mechanismen
Worum es auf diesen Seiten geht