v1.1.4.0 FS25_16xMapFix

FS25_16xMapFix

FS25 16x-Map-Fix – die eigentliche Ursache + ein Tool zur Behebung

Warum 16x- (und größere) Karten im Landwirtschafts-Simulator 25 mit einem „allocReg“-Fehler abstürzen
oder bei „100 % Shader-Kompilierung“ hängen bleiben – hier ist die vollständige Diagnose sowie ein Tool,
das das Laden und die Synchronisierung im Multiplayer auf normaler Hardware ermöglicht.

Wichtig
Gefällt dir das Tool?
Du kannst die Entwicklung auf Ko-fi unterstützen – bitte erwähne dabei „16x Map Fix“, damit ich weiß, woran ich weiterarbeiten soll.
Diagnostiziert auf einem Dedicated Server und einem Client mit 16 GB RAM, auf denen dieselbe 16x-Karte lief.
Das Tool reduzierte die „allocReg“-Fehler bei einer echten 16x-Karte von 878.987 auf 0 und machte sie im Multiplayer spielbar.

Kurz gefasst (TL;DR)
Der „allocReg“-Absturz beruht eigentlich auf zwei verschiedenen Problemen, die identisch aussehen:
Ursache Lösung
Einzelspieler Speicherbedarf – eine 16x-Karte benötigt ca. 20–32 GB während der ersten Kompilierung der Dichte-Daten (Density Maps); 16 GB reichen nicht aus
Eine große Auslagerungsdatei (48 GB+) + DX11 → die originale, unveränderte Karte lädt Multiplayer
Eine Tile-Registry mit fester Kapazität im Synchronisierungsmodul für Dichte-Karten läuft bei 16384px-Dichte-Karten über Verkleinerung der beschreibbaren Dichte-Layer der Karte auf 8192px – siehe Tool unten

Der Beweis, dass es sich im Multiplayer nicht um ein RAM-Problem handelt: Ein Dedicated Server mit 262 GB RAM verursachte dennoch dieselben 3014 „allocReg“-Fehler. Mehr RAM oder eine größere Auslagerungsdatei helfen im Multiplayer nicht – nur weniger Tiles schaffen Abhilfe.
Ursache im Detail

Bei den überlaufenden Layern (Früchte, Boden, Unkraut, Info-Layer) handelt es sich um die beschreibbaren „Terrain-Detail“-Dichte-Karten des Spiels – man pflügt, sät und erntet darin, überall, auch außerhalb des sichtbaren Bereichs, und der Server überwacht die gesamte Karte. Beschreibbare Daten können kein „Virtual Texturing“ nutzen (bei dem nur sichtbare, schreibgeschützte Tiles gestreamt werden); daher müssen diese Layer vollständig im Speicher liegen und registriert sein. Ihr Ressourcenbedarf skaliert mit der Kartenfläche: 16x bedeutet die 16-fache Anzahl an Tiles. Im Einzelspielermodus lädt der Client seine eigenen, bereits fertiggestellten .gdm-Dateien; der einzige Engpass ist der kurzzeitige Anstieg des Speicherbedarfs während des ersten Kompiliervorgangs, der jedoch durch eine ausreichend große Auslagerungsdatei (Pagefile) abgefangen wird.
Im Mehrspielermodus überträgt der Server die Dichtekarten (Density Maps) an jeden beitretenden Client, der diese live über die Kachel-Registry mit fester Größe (TiledBitmapOperationCompiler) neu kompiliert. Eine Dichte von 16384 Pixeln führt zu einem Überlauf – und damit zu Tausenden von „allocReg“-Vorgängen. Dies stellt eine harte Kapazitätsgrenze dar, die nicht vom Arbeitsspeicher (RAM) abhängt; genau deshalb scheitern selbst Server mit 262 GB RAM, und deshalb liegt die effektive Obergrenze von GIANTS für den Mehrspielermodus bei der vierfachen Standardgröße (4x): Eine 4x-Karte ist das größte Gebiet, dessen beschreibbare Dichte sowohl in die Registry als auch in die Synchronisation pro Verbindung passt.
Das Tool

tool/mapfix.py + tool/Optimize-Map.bat (Windows Drag & Drop). Es skaliert jede überdimensionierte Dichte- oder Info-Ebene (16384 Pixel, Zweierpotenz) einer Karte auf die für die Engine sicheren 8192 Pixel herunter – genau die Auflösung, mit der funktionierende 4x-Karten ausgeliefert werden. Dabei bleiben Feld- und Fruchtinformationen erhalten (Dekodierung → Resampling per „Nearest Neighbour“ → erneute Kodierung; verifiziert als zu 99,9 % pixelidentisch, Fruchtbedeckung unverändert). Höhenkarten und Geländegeometrie (dem.png, Raster mit 2ⁿ+1 Punkten) werden anhand ihrer Größe (keine Zweierpotenz) erkannt und nicht verändert.

Anwendung

Ziehe deine Karten-ZIP-Datei auf die `Optimize-Map.bat` (erfordert Python 3 – Pillow wird automatisch installiert).
Eine Datei mit dem Suffix `_fixed.zip` wird im selben Ordner erstellt – deine Originaldatei bleibt unverändert.
Lade die korrigierte Karte auf deinen Server hoch, starte einen neuen Spielstand (wichtig: alte Spielstände enthalten die alte Dichte-Revision) und tritt dem Spiel bei.

Enthält `grleconvert` (MIT-Lizenz) für die Konvertierung zwischen .gdm/.grle und PNG. Unterstützt 16x- und 32x-Karten; die Ausgabe erfolgt immer im sicheren 8192-Pixel-Format.
Hinweis zum Multiplayer (GIANTS-Autosave)

Selbst mit einer korrigierten Karte führt der Dedicated Server von GIANTS einen blockierenden Autosave durch (`auto_save_interval`, Standard: 10 Min.). Bei großen Karten hält dieser Speichervorgang den Haupt-Thread so lange an, dass die Verbindung zum Client genau in diesem Moment abbrechen kann („Verbindung verloren“), während der Server selbst online bleibt. Erhöhe den Wert für `auto_save_interval` in der `dedicatedServerConfig.xml` (z. B. auf 30–60), um dieses Problem zu minimieren.
Zusatz-Mod: Auto VRAM Optimizer

Eine kleine, eigenständige Mod, die das Limit für das Textur-Streaming im FS25 (standardmäßig ca. 4 GB) auf den tatsächlichen VRAM deiner Grafikkarte anhebt. Dies sorgt für flüssigeres Laden und weniger Pop-ins bei allen Grafikkarten mit mehr als 4 GB VRAM – nicht nur bei 16x-Karten:

➡️ https://github.com/KeilerHirsch/FS25_AutoVRAMOptimizer