Je crois qu'il n'y a pas de tuto sur la confrérie sur comment "installer" le memory patch avec SKSE 1.7.1 (ou version supérieure)
Donc petite contribution pour le bien de tout le monde.
Un memory patch ? L'explication simple
Skyrim a accès à une quantité limitée de mémoire lorsqu'il travaille, et doit sub-diviser cette mémoire entre différentes tâches. Malheureusement, dans le code du jeu, l'une de ces tâches à tendance à souvent excéder la mémoire qu'elle s'est vue attribuer dans le cas d'un jeu moddé. Et le système de sécurité mis en place pour contourner le problème est complètement buggué et fais planter votre jeu presque à chaque fois qu'il se met en route.
Ce patch augmente la taille de la mémoire disponible pour cette tâche, ce qui fait que la fonction buggé n'aura jamais à se mettre en route.
Exemple de problèmes inhérents à cette erreur de gestion de mémoire :
Infinite Loading Screens (ILS), c'est à dire
Temps de chargement infini.
Crash To Desktop (CTD), ou encore
Retour au bureau en français, lors de l'entrée dans une nouvelle zone extrêmement "pleine".
CTD lorsque beaucoup de PNJ apparaissent.
Un memory patch ? L'explication moins simple
► Afficher le texte
Comme n'importe quel programme informatique, au lancement du jeu, Skyrim se voit attribuer de la mémoire par votre système. Cette mémoire est limitée est dépends de votre OS (~2Gb avec un OS 32bit, ou ~3.1Gb avec un OS 64bit).
Skyrim étant un jeu 3D avec de l'Intelligence Artificielle, de la physique et tout le tralala, il s'agit d'un programme extrêmement complexe, contenant une multitude de "sous-programmes" (tels que le moteur graphique, le moteur de simulation de la physique, l’interpréteur papyrus, ...) qui interagissent entre eux pour le résultat final.
Encore plus fifou, chacun de ces sous-programmes a un certain nombre (souvent dynamique) de threads. Si vous n'avez aucune notion de programmation, imaginez les threads comme les bras d'un programme, plus il en a, plus il peut faire de chose à la fois.
Pour être sur que chacun de ces "sous-programmes" fasse sont boulot correctement, Skyrim va à son tour leur attribuer une fraction de la mémoire que lui même s'est vu attribuée par le système à son lancement.
Pour certains d'entre eux, dont le rôle est de "mettre en tampon" un certain nombre d'information, une partie de la mémoire est attribuée de façon fixe au lancement du jeu pour être utilisée comme tampon. C'est ce qu'on appel un bloc de mémoire.
En cas de situation stress intensif, l'un de ces blocs nommé le "
heap cache" se retrouve assez systématiquement saturé, car c'est lui qui met en tampon le plus de trucs. Pas de traduction littérale de "heap cache" à vous donner, mais "heap", c'est "un tas" ou "une pile", et "cache" peut se traduire par "tampon" au sens informatique... ça vous donne une idée
C'est typiquement lui qui souffre le plus d'un jeu lourdement moddé, puisque c'est par lui que passent toutes les informations qui sont relatives aux éléments présents dans les cellules actuellement chargée.
Quand le heap cache est plein, Skyrim va essayer de lui attribuer un deuxième bout de mémoire (bloc) temporairement, histoire qu'il puisse continuer à travailler le temps que le premier bloc n'aie été vidé.
Evidemment, Skyrim ayant lui-même une quantité de mémoire limitée à distribuer à ses sous-programmes, cette opération pour faire "survivre" un des sous-programmes se fait au détriment des autres sous-programmes, qui ne pourront pas bénéficier du même traitement de faveur si ils viennent à leur tour à saturer leur bloc.
Les développeurs de chez Beteshda ont donc optimisé la taille initiale de ces différents blocs de mémoire pour les différents sous-programmes, de façon à ce qu'il puissent faire leur boulot avec quasiment aucun problème, tout en gardant une marge de sécurité pour lui même (il a aussi besoin de mémoire pour jouer son rôle de chef d'orchestre), ainsi que du "surplus" à redistribuer au cas où une situation de stress particulière se présenterait.
Et alors, le problème ? Au pire, tu nous as expliqué que dans ce cas, Skyrim donne temporairement un peu plus de place à ce bloc, donc tout est bon non ?
C'est là qu'est le soucis, la fonction qui est sensé attribuer le nouveau bloc est complètement buggée, et fera crasher votre jeu en essayant de s'exécuter dans 95% des cas. (chiffre bidon, disons juste que c'est quasi-systématique)
La solution magique offerte ici, c'est d'augmenter la taille initiale du bloc (celle attribuée au lancement du jeu), afin de faire en sorte que cette fonction n'aie jamais à être utilisée.
Mais on risque pas d'atteindre quand même la limite à un moment ou un autre ?
Si, d'où l'importance de configurer la taille initiale selon ses besoins (Le jeu vanilla se débrouille très bien avec la taille non-modifiée, donc votre jeu moddé peut également trouver un équilibre).
A noter tout de même qu'il s'agit bien d'un tampon, sa taille ne fait pas
que d'augmenter, différentes fonctions permettent de "décharger" le bloc, laissant de la place pour y mettre d'autres trucs par la suite.
Et donc, si on augmente la taille initiale et que j'ai tout suivi ce que tu as dit jusqu'à maintenant, ça veut dire que le reste du jeu aura moins de mémoire disponible pour travailler ? C'est pas un peu dangereux ?
Une fois de plus : Si, et c'est pour ça qu'il est important de configurer la taille de cette mémoire selon ces besoin, et pas se dire "je la fous au max, comme ça je suis tranquille".
Le problème de heap cache est la source n°1 de crashs sur une configuration moddée correctement* , et ce correctif a été testé et approuvé par des gens du genre super-compétents, donc ce petit sacrifice de mémoire vaut le coup, et est safe d'utilisation si vous le paramétrez correctement.
*
après, si vous avez oublié des patchs de compatibilité pour certains mods, n'avez pas nettoyez vos plugins avec TES5Edit, utilisez des mods buggés, ou avez oublié de trier votre load order, vous en aurez d'autres... mais il ne s'agit pas d'une "configuration moddée correctement" 
Pour répondre précisément à la question : Oui, il est possible que le fait d'attribuer plus de mémoire à ce bloc aie des effets secndaires négatifs actuellement indétectables sur le fonctionnement du jeu. Ce qui est sur, c'est qu'il corrige parfaitement un bon paquet de problèmes parfaitement détectables, sans effets secondaire apparents à l'heure actuelle, après plus d'un an de fonctionnement sur des milliers d'installation différentes.
Commencez par vous rendre sur la page du SKSE, et téléchargez la dernière version. Le patch est seulement utilisable à partir de la version 1.7.1 (la version actuelle est 1.7.3).
Téléchargez la version archive en cliquant sur "
7z archive" sur ce lien :
http://skse.silverlock.org/
Quand vous avez cette archive, vous la décompressez, puis vous placez le tout dans votre dossier Skyrim en vous assurant que "skse_loader" soit bien dans le dossier .../Steam/SteamApps/common/Skyrim (et donc que le dossier Data de l'archive fusionne avec le dossier Data de votre Skyrim déjà présent).
Liste des fichiers qui doivent être dans ce dossier :
► Afficher le texte
Data (dossier)
src (dossier)
skse_1_9_32.dll
skse_docs.txt
skse_loader.exe
skse_papyrus_docs.txt
skse_readme.txt
skse_steam_loader.dll
skse_whatsnew.txt
: Si vous utilisez Mod Organizer, une bonne chose à faire est de ne pas copier le dossier Data directement, mais de le repackager en une archive et de l'installer via MO.
Euh, là on a juste installé le SKSE non ?
Si !
Vous voilà avec le dernier SKSE à jour et complet, maintenant, reste à appliquer le petit "tweak" qui va vous permettre d'adresser notre problème de bloc mémoire :
Dans votre dossier Data :
Créez un sous-dossier SKSE (si vous n'en avez pas déjà un)
Créez un fichier SKSE.ini dans ce sous-dossier (si vous n'en avez pas déjà un)
Ouvrez le (notepad ou notepad++) et copiez y ces lignes :
Code : Tout sélectionner
[General]
ClearInvalidRegistrations=1
EnableDiagnostics=1
[Display]
;iTintTextureResolution=2048
[Memory]
defaultHeapInitialAllocMB=768
scrapHeapSizeMB=256
Sauvegardez et fermez.
Et voilà ! Votre skyrim est maintenant patché
Attention : Ce correctif ne fonctionnera que si vous lancez le jeu via SKSE (voir le topic sur SKSE pour plus de détails si vous ne savez pas ce que c'est :
http://www.confrerie-des-traducteurs.fr ... 83&t=10213)
Ajuster les valeurs à ses besoins :
Bien évidemment, si vous avez un jeu vraiment très moddé, il se peut que les valeurs par défaut données plus haut ne soient pas suffisantes, et que quoique moins fréquents, les problèmes persistes.
Vous pouvez ajuster la valeur de
defaultHeapInitialAllocMB dans la section [Memory] si vous remarquez que vous avez toujours des soucis (incrémenter par multiples de 256).
Ne pas modifier sans avoir fait des tests avec les valeurs données ! Si le patch marche avec ces valeurs, ne cherchez pas à les changer ! (voir "l'explication moins simple" ci-dessus pour comprendre pourquoi).
Pour configurer précisément la taille du bloc, la bonne chose à faire est d'utiliser le memory bloc log :
lien nexus
(plus d'information sur comment l'utiliser correctement quand j'aurai le temps d'écrire tout ça...
)
Il n'y a aucune raison de modifier la valeur de
scrapHeapSizeMB, excepté pour les utilisateurs qui ont mal configurés ENBoost, mais c'est une autre histoire... donc ce paramètre devrait toujours être laissé à 256
A propos de "Safety Load" :
J'ai dit que ce patch corrigeait un problème à la source des écrans de chargement infinis (connus sous le joli nom d'ILS) en plus des crash intempestifs. Ce qui était le rôle du mod correctif "Safety Load". La question est : Est-ce que ce dernier est obsolète ?
La réponse est oui,même si il est vrai que les deux font des choses parfaitement différentes.
En simple, Safety Load est plutôt destructif : si il évite le bug sur certains écrans de chargement, en revanche, pour tous les autres écrans de chargement qui n'auraient pas été buggé, il va empêcher la mémoire de s'auto-optimiser (cette auto-optimisation étant à la source des ILS), réduisant les capacités du jeu le temps qu'il se remette les idées au clair. Ça n'a jamais été reporté comme ayant des conséquences dramatiques, mais si on peut s'en passer, autant le faire
Pour comprendre les détails qui suivent, vous aurez besoin d'avoir lu "l'explication moins simple" (Deuxième paragraphe).
► Afficher le texte
Il existe une autre fonction de gestion de mémoire, dont le rôle est de vider le heap cache de ce qu'il contient d'inutile. Malheureusement, elle est buggé également : si il n'y a rien à vider, la fonction attends jusqu'à ce qu'elle ai finalement réussi à enlever quelque-chose... ce qui en cours de jeu arrivera, mais pour certains écrans de chargement (typiquement, changement de worldspace) risque de ne jamais arriver. En revanche, ça garde la mémoire dans un état "propre" le reste du temps.
Safety Load est un correctif destructif, il ne corrige pas réellement le bug : il empêche simplement cette fonction de s’exécuter. Quand il est actif, ce qu'il y a d'inutile en mémoire n'est donc jamais supprimé par cette fonction. Ce ne sera retiré que par d'autres fonctions, à d'autre moments.
Si vous avez correctement configuré votre memory patch, cette fonction qui risque d'attendre à l'infini ne sera jamais lancée à tort, car la situation de stress problématique n'aura jamais lieu (Le jeu ne cherche pas à nettoyer le heap cache lors des écrans de chargement si il a suffisamment de mémoire encore disponible). En revanche, elle continuera de faire son boulot proprement le reste du temps.
Si vous avez encore des ILS, c'est que la situation de stress se présente encore, et que vous avez besoin d'augmenter encore un peu la taille du bloc via le memory patch.
- La ligne avec iTintTextureResolution dans la section [Display] que je vous ai fait copier-collé peut être "activée" en retirant le point-virgule en début de ligne. Faites le si vous utilisez des textures en ultra HD (comme celles de XCE par exemple) pour les TintMasks, c'est à dire les peintures de guerre, tatoos, maquillages, etc... Ne l'activez surtout pas si vous n'avez pas ce genre de textures ! Ou vos overlays pour les peintures de guerre, vos lèvres et tout un tas de trucs vont apparaître ultra-pixelisés.
- Si vous avez déjà utilisé le SSME auparavant (version du memory patch originelle par Sheson, pas directement implémentée dans SKSE et désormais obsolète), vous avez surement utilisé des valeurs de bloc mémoire différentes de celles que je vous ai données dans le fichier .ini qui y correspondait. La version SKSE n'est pas exactement codée pareille que l'était le SSME, c'est pourquoi les valeurs conseillées sont différentes. Le fonctionnement en lui-même est exactement le même. De même, les autre valeurs dans le .ini ne sont plus d'actualité, celles données précédemment sont suffisantes)
- Si vous avez peur de vous rater sur la création du fichier SKSE.ini au bon endroit, ou de rater votre copier-coller, Sagittarius a uploadé le fichier dans sa configuration "par défaut" ici :
SKSE ini pre-download for lazy users , vous pouvez installer ça comme un mod normal et tout se passera bien
Ce patch augmente la stabilité du jeu, pas les performances de votre ordi a proprement parler ! Donc n'espérez pas avoir rendu votre jeu plus rapide/fluide en installant ceci ! Tournez vous vers
ENBoost si c'est ce que vous cherchez (ou éventuellement HiAlgoBoost, mais c'est de la m**** si vous voulez mon avis...)
)