SourceEngine La mémoire ne peut pas être READ

  • Initiateur de la discussion
  • Administration
Seb

Seb

El Dictator
Membre du Staff
Messages
1 875
Score réaction
454
Points
370
Ce tutorial réalisé entièrement par MC_RaT et provient des archives de mapping-area et modding-area.
Les archives sont anciennes, certains tutoriels peuvent ne plus correspondre aux dernière versions.


-

Qui n'a jamais eu une erreur de ce type en mappant sous HL² :

Code:
L'instruction à "0x..." emploie l'adresse mémoire "0x...". La mémoire ne peut pas être "read"

Cette erreur est très courante lorsque l'on mappe avec le Source Engine et je vais tenter de clarifier ce que cela veut dire et pourquoi cela se produit.

Myst à dit:
Ca fait plus d'une heure que je cherche sur le forum et je trouve pas donc voila:
Je compile ma map tout a l'air de bien aller.
Je crée la partie je choisi ma team. je bouge un peu la vue puis vlan bug et le jeu ferme.
erreur memory "read" ou quelque chose comme ca.
J'ai effacer presque toute la map puis j'ai réessayer et ca marche.
Comme si quelque chose prennait trop de jus et qui fesait planté.
Pourtant la map est très "basique"

D'après moi, ce que Myst raconte est le meilleur exemple tant au niveau du problème que de l'explication. J'ai moi même eu cette erreur de très nombreuses fois.

NykO18 à dit:
Moi j'ai pas hammer qui plante, mais quand Half-Life 2 se lance après une compilation j'ai un beau "Error in model models/hostage*.vvd" ou un truc du genre.. puis un "Memory error: la mémoire ne peut pas être read.."
Une erreur de 'mémoire ne peut pas être "read"' peut correspondre à ÉNORMÉMENT de choses. Il existe une page propre à Steam sur steampowered.com où ils expliquent que cette erreur provient assez souvent, et sur le Source Engine en particulier.

Elle peut provenir de n'importe quel jeu ou de n'importe quel logiciel qui peut être en conflit avec n'importe quel matériel à n'importe quel moment et pour n'importe quelle raison. Cette erreur vient uniquement d'un logiciel/programme mal codé. Et j'ai également ce problème avec plusieurs autres programmes qui entrent eux-même en conflit avec autre chose.

Pour ceux qui ne codent pas en C ou autres langages très stricts au niveau de l'allocation mémoire, je vais tenter de vous expliquer le pourquoi du comment..
Imaginons que vous ayez un programme A et un programme B différents qui tournent en même temps. Imaginons également que ces deux programmes aient été codés par VALVe... ouch, ils sont donc très instables et très mal codés...

Maintenant, imaginons qu'à un moment T le programme A décide d'écrire une information en mémoire à l'adresse X. Jusque là, pas de problème, mais imaginons en plus que le programme B décide au même moment de faire la même chose ! On a donc, deux programmes qui tentent d'écrire au même endroit de la mémoire et là.. c'est le drame. Imaginons maintenant que le programme A ait été TRÈS mal codé.. Et que tout à coup, il décide d'écrire dans une région de la mémoire où il n'a absolument pas le droit d'écrire.. Soit en dehors de la mémoire carrément à une adresse qui n'existe pas, soit sur un endroit déjà utilisé, ou pire.. et hop, à nouveau un crash.

C'est une vision assez simpliste, mais ça explique plutôt bien ce qui se produit au niveau software/hardware. Lorsque vous créez une map et qu'en la lançant vous obtenez une erreur de mémoire, c'est uniquement la faute de votre map (selon VALVe) mais en fait uniquement la faute de VALVe (selon les mappeurs)..
C'est parce que vous avez créé quelque chose sur cette map (et cela peut être n'importe quoi) qui n'est pas ou mal pris en charge par le code de VALVe situé derrière le jeu.

D'un côté c'est la faute de VALVe de ne pas avoir créé un code assez propre, et de l'autre c'est votre faute, pour être sorti du rang.
Cela peut également être dû, mais plus rarement je pense, à un programme extérieur qui tournerait sur votre machine en même temps que HL² et qui bousillerait la zone mémoire ou HL² travaille.. Une fois de plus parce que c'est mal codé. Tout est affaire d'allocation mémoire et de compatibilité entre programmes.

Je rajoute que, contrairement aux idées reçues qu'on peut lire, ce n'est pas parce que vous aurez 15 Go de mémoire que ça marchera mieux. Changer de barrettes mémoire n'apportera rien non plus.
Une explication que je pourrais donner à cette "affluence" d'erreurs de mémoire sur le jeu Half-Life 2 en particulier, est qu'il ne faut pas oublier que le code source du jeu a été volé à une ou deux reprises au cours de son développement, et les programmeurs se ont vu obligés d'en recoder une très grosse partie en un temps réduit pour éviter les détournements et les triches en multijoueurs... Il ne faut donc pas s'étonner qu'ils n'aient pas eu le temps de faire un jeu parfait à temps.

Il y a également une autre explication, de lamar-css, mais je n'ai pas vérifié la véracité de ses dires. Je suppose que c'est véridique tout de même :

lamar-css à dit:
Salut moi j ai eu le meme problème et en fait quand tu joues, tu bouges (logique on se promène dans un environnement 3D) tu regardes le décor et en fait l'ordinateur traite a la micro ou miliseconde je sais plus laquelle, des infos des brush sur les axes x;y;z . Le problème survient en fait en variance de la machine sur laquelle tu joues car c'est soit tu as dépasser la maximum de brush en valeur légale, soit l'ordinateur n'arrive pas a traité assez rapidement un certain nombre d'informations en même temps donc l'effet produit est que le processeur crée un décalage et la RAM se retrouve avec un "vide" d'info donc renvoi automatiquement une info prioritaire au processeur (en fait a "l'horloge" qui décal sa fréquence n Mhz:) c'est bizzard et compliqué je sais...).
Donc cette info prioritaire annule simplement les autres car si elle ne parvient pas en un certain laps de temps soit ton pc se bloque soit plus généralement avec les nouveau s'éteint pour la sécurité car il y a un décalage éléctrique qui déstabilise le système. Si cette info parvient il existe deux théories (sachant que l'on retrouve généralement la 2eme). La première théorie est que le processeur reprend le travail normalement avec beaucoup de "lags", soit la deuxième qui constiste à ce que notre fainéant de processeur (si si c'est vrai ce sont de vrai dormeur) ne se casse pas la tête prend la dernière ligne de commande qu'il a exploité et te donne le message d'erreur ainsi que l'origine: genre un code binaire ou hexa incompréhensible...

Voilà c'est ce qui sa passe dans pas mal de cas mais peu etre ce n'est pas ce qui est arrivé mais c'est bon a savoir.
 
Discord Hytale, Minecraft, Rust, ARK, FiveM

Découvrez mTxServ!

Discord d'entraide

Rejoignz-nous sur Discord