FS25 16x Map Fix – la cause première + un outil pour y remédier
Pourquoi les cartes 16x (et plus) dans Farming Simulator 25 plantent-elles avec une erreur « allocReg »
ou rester bloqué sur "100% Shader Compilation" ? Voici le diagnostic complet ainsi qu'un outil
qui permet le chargement et la synchronisation en multijoueur sur du matériel normal.
Important :
Aimez-vous l’outil?
Vous pouvez soutenir son développement sur Ko-fi – veuillez mentionner « 16x Map Fix » pour que je sache sur quoi travailler ensuite.
Diagnostiqué sur un serveur dédié et un client avec 16 Go de RAM, tous deux exécutant la même carte 16x.
L'outil a réduit les erreurs "allocReg" sur une véritable carte 16x de 878 987 à 0, la rendant jouable en multijoueur.
En bref (TL;DR),
le crash de "allocReg" est en réalité causé par deux problèmes différents qui semblent identiques :
Cause Solution
Mémoire requise pour un joueur unique – une carte 16x nécessite environ 20 à 32 Go lors de la compilation initiale des données de densité (cartes de densité) ; 16 Go, c'est insuffisant.
Un gros fichier d'échange (48 Go+) + DX11 → la carte originale non modifiée se charge. Multijoueur
Un registre de tuiles avec une capacité fixe dans le module de synchronisation des cartes de densité fonctionne en réduisant la couche de densité inscriptible de la carte à 8 192 pixels pour les cartes de densité de 16 384 px – voir l'outil ci-dessous.
Preuve qu'il ne s'agit pas d'un problème de RAM en multijoueur : un serveur dédié avec 262 Go de RAM produisait toujours les mêmes erreurs 3014 "allocReg". Plus de RAM ou un fichier d'échange plus volumineux n'aident pas en multijoueur – seul moins de tuiles résolvent le problème.
La cause en détail.
Les couches débordantes (fruits, sol, mauvaises herbes, couche d'informations) sont les cartes de densité "détails du terrain" inscriptibles du jeu : vous labourez, semez et récoltez à l'intérieur, partout, même en dehors de la zone visible, et le serveur surveille l'intégralité de la carte. Les données inscriptibles ne peuvent pas utiliser la « texturation virtuelle » (où seules les tuiles visibles en lecture seule sont diffusées) ; par conséquent, ces couches doivent résider entièrement en mémoire et être enregistrées. Leurs besoins en ressources évoluent avec la zone de la carte : 16x signifie 16 fois le nombre de tuiles. En mode solo, le client charge ses propres fichiers .gdm précompilés ; le seul goulot d'étranglement est le bref pic d'utilisation de la mémoire lors de la compilation initiale, qui est gérée par un fichier d'échange suffisamment volumineux.
En mode multijoueur, le serveur transmet des cartes de densité à chaque client adhérent, qui les recompile en direct via le registre de tuiles de taille fixe (TiledBitmapOperationCompiler). Une densité de 16 384 pixels entraîne un débordement — et donc des milliers d'opérations " allocReg ". Cela représente une limite de capacité stricte indépendante de la RAM ; c'est précisément pourquoi même les serveurs dotés de 262 Go de RAM échouent, et pourquoi la limite supérieure effective de GIANTS pour le mode multijoueur est quatre fois la taille standard (4x) : Une carte 4x est la plus grande zone dont la densité d'écriture s'intègre à la fois dans le registre et dans la synchronisation par connexion.
L'outil
tool/mapfix.py + tool/Optimize-Map.bat (glisser-déposer Windows). Il réduit toute densité ou couche d'informations surdimensionnée (16 384 pixels, puissance de deux) d'une carte à 8 192 pixels, sans danger pour le moteur, soit précisément la résolution à laquelle des cartes 4x fonctionnelles sont fournies. Les informations sur les champs et les cultures sont préservées (décodage → rééchantillonnage via « voisin le plus proche » → réencodage ; vérifié comme étant identique à 99,9 % aux pixels, couverture des cultures inchangée). Les cartes d'élévation et la géométrie du terrain (dem.png, raster avec 2ⁿ+1 points) sont reconnues en fonction de leur taille (et non d'une puissance de deux) et ne sont pas modifiées.
Demande
Faites glisser le fichier ZIP de votre carte dans le dossier « Optimize-Map.bat » (nécessite Python 3 – Pillow sera installé automatiquement).
Un fichier avec le suffixe « _fixed.zip » sera créé dans le même dossier – votre fichier d'origine reste inchangé.
Téléchargez la carte corrigée sur votre serveur, démarrez une nouvelle partie (important : les anciennes sauvegardes contiennent l'ancienne révision de densité) et rejoignez la partie.
Inclut `grleconvert` (licence MIT) pour la conversion entre .gdm/.grle et PNG. Prend en charge les cartes 16x et 32x ; la sortie est toujours au format sécurisé de 8 192 pixels.
Remarque concernant le multijoueur (sauvegarde automatique GIANTS).
Même avec une carte graphique corrigée, le Serveur Dédié GIANTS effectue une sauvegarde automatique bloquante (`auto_save_interval`, par défaut : 10 minutes). Avec les grandes cartes graphiques, ce processus de sauvegarde bloque le thread principal pendant si longtemps que la connexion au client peut être interrompue à ce moment précis (« connexion perdue »), tandis que le serveur lui-même reste en ligne. Augmentez la valeur de « auto_save_interval » dans « dedicatedServerConfig.xml » (par exemple, à 30-60) pour minimiser ce problème.
Mod supplémentaire : Optimiseur automatique de VRAM
Un petit mod autonome qui augmente la limite de streaming de texture dans FS25 (environ 4 Go par défaut) à la VRAM réelle de votre carte graphique. Cela se traduit par un chargement plus fluide et moins de pop-ins pour toutes les cartes graphiques dotées de plus de 4 Go de VRAM, et pas seulement pour les cartes 16x.
