Bastelhof/Bastelhof_TruckSim_MapStudio
Watch
1
0
Fork
You've already forked Bastelhof_TruckSim_MapStudio
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Page: Virtuelles Dateisystem
Pages
ADR 0001 Clean Room Entwicklung ADR 0002 Nativer Kartenrenderer ADR 0003 Phase 0 Abhängigkeiten Architektur Archivzugriff Benutzerhandbuch Build und Entwicklung Changelog Clean Room Richtlinie Datenformate Exportprofile HashFS Clean Room Spezifikation Home Modpaket Metadaten Projektstatus Projektübersicht Quellenregister Roadmap SCS Profil Klartextteilmenge SII Klartextparser Steam Erkennung Synthetische Profilfixtures Verhaltensnotizen Virtuelle Pfade Virtuelles Dateisystem
1 Virtuelles Dateisystem
Batista82 edited this page 2026-07-30 18:22:36 +02:00
Table of contents

Virtuelles Dateisystem und Mods

Ziel

Phase 2 führt Basisspiel, DLCs und aktive Mods zu einer read-only Dateisicht zusammen.

Prioritäten

Die Reihenfolge folgt dem Prinzip:

Basisspiel
-> DLCs
-> aktive Mods in Spielreihenfolge
-> höchste Priorität gewinnt

Jede Quelle wird als VirtualFileSystemLayer mit Priorität eingebunden. Bei identischen virtuellen Pfaden gewinnt die Quelle mit der höchsten Priorität.

Herkunft und Konflikte

Für jeden sichtbaren Pfad werden gespeichert:

  • sichtbare Herkunft
  • alle bekannten Herkünfte in Prioritätsreihenfolge
  • Konflikte durch überlagerte Pfade

Konflikte werden als VirtualFileConflict gemeldet und können in späteren UI-Schritten angezeigt werden.

Mod-Ladereihenfolge

ModLoadOrderService filtert deaktivierte Mods, sortiert aktive Mods nach Priorität und erzeugt einen stabilen SHA-256-Hash der Modkombination.

Fehlende Abhängigkeiten werden als Warnungen gemeldet. Die Verarbeitung bricht dadurch nicht ab.

Profilbasierter Aufbau

ProfileVirtualFileSystemBuilder übersetzt ein geladenes GameProfile in VFS-Layer:

  • Basisspielquelle mit niedriger Priorität.
  • Optionale DLC-Quellen oberhalb des Basisspiels.
  • Aktive Mods oberhalb von Basisspiel und DLCs.

Unterstützte Quellen sind aktuell Verzeichnisse und ZIP-basierte .scs-Archive. HashFS-Archive werden erkannt und mit Diagnose gemeldet, aber nicht in die native VFS-Sicht eingebunden.

ProfileWorkspaceLoader lädt einen synthetischen Arbeitsbereich mit Profil-JSON, base/, optionalem dlc/ und Modquellen. Die WinUI-App lädt im Entwicklungsbetrieb vorhandene Phase-2-Fixtures aus tests/Fixtures/Phase2/ und kann zusätzlich über „Arbeitsbereich auswählen“ ein anderes synthetisches Arbeitsverzeichnis laden.

Fehlen die Entwicklungsfixtures, bleibt die Anwendung ohne künstliche Beispieldaten im neutralen Anfangszustand.

SCS-Profile und lokale Modquellen

ScsProfileFileReader liest die dokumentierte Phase-2-Klartext-Teilmenge von profile.sii und meldet nicht direkt unterstützte Dateien mit Diagnosecodes. Für binäre oder verschlüsselte Profile gibt es den Adaptervertrag IScsProfileDecoder; ExternalScsProfileDecoderAdapter kann ein vom Benutzer konfiguriertes, lokal vorhandenes Decoderwerkzeug anbinden und verarbeitet dessen Klartextausgabe weiter über denselben Parser.

ScsProfileModResolver löst belegbare Mod-IDs aus Profilen gegen lokale Modverzeichnisse und ZIP-basierte .scs-Pakete auf. Metadaten stammen aus manifest.sii; fehlt ein Paket lokal, bleibt die Profilreferenz bewusst erhalten und wird nicht durch erfundene Daten ersetzt.

Aktuelle Grenzen

  • Native Dekodierung proprietärer binärer oder verschlüsselter SCS-Profile ist nicht Teil der Phase-2-Clean-Room-Implementierung; solche Dateien werden nur über einen explizit konfigurierten externen Decoder verarbeitet.
  • Die implementierte SII-Unterstützung ist eine dokumentierte Profil- und Modmanifest-Teilmenge, keine vollständige globale SCS-SII-Spezifikation.
  • Tests verwenden weiterhin ausschließlich synthetische Fixtures.
  • Die Oberfläche zeigt Profilname, Modkombinations-Hash, Modliste, Modwarnungen und Dateikonflikte.