Annexe : les erreurs de compilation

En premier lieu, sachez que le RAD est, des quatre calculateurs, le plus enclin à utiliser la mémoire de votre machine. Le calcul du RAD est appellé Vismatrix que l'on assimilera à une "puissance de calcul " qui augmente ou diminue de taille en fonction des lumières utilisées, des blocs sur lesquelles elles agiront et donc de l'architecture de votre map. C'est pourquoi le RAD a besoin des résultats du VIS pour effectuer sa tâche Nous dirons donc que plus le vismatrix augmentera de taille, plus le RAD sera gourmant en ressources. La formule déterminée que l'on doit prendre en compte est à peu près égale à la racine carrée du nombre de patchs créés . Ainsi, si l'on prend en compte le nombre maximal de patches que le RAD peut créer sur une map, à savoir 65535, nous en déduisons que le vismatrix maximal est à peu près égal à 256 Mo.

Néanmoins, ce poids du vismatrix obtenu n'est pas égal à ce dont le RAD à réellement besoin pour calculer. ( Heureusement! ) Pour connaître le réel besoin du RAD, la formule habituelle est +/- égale à la moitié du poids du vismatrix (je sais, je sais ça se complique...:( ) Soit, pour notre exemple maximal:

Pour 65535 patches créés, le vismatrix sera à peu près égal à 256 Mo et les besoins du RAD seront donc +/- équivalants à 128 Mo. Tout en sachant que cette valeur pourra changer quelque peu, en fonction de l'organisation et le détail de votre map.

Vous pourrez rencontrer des problèmes lors de votre compilation, au moment du calcul du RAD et souvent vous vérifierez cela sur la fin de la phase "MakeScale". Au début de cette phase spécifique le RAD aura pris pleine possession de votre mémoire et le MakeScale pourra donc parfois s'executer convenablement jusqu'à 90% de son travail. Mais les 10% manquants vous paraîtrons prendre un temps interminable. C'est que le RAD cherche à puiser dans vos ressources une mémoire qui n'est pas forcement disponible..

Ainsi si vous ne possédez pas une quantité de mémoire suffisante ( un minimum de 256Mo est vivement conseillé ) et que votre map est relativement grande ou complexe, vous pourrez parfois attendre plusieurs jours avant la fin de la compilation. Vous en déduisez donc les conclusions suivantes: Il vous faudra simplifier et bien structurer vos maps en petites pièces, en attendant que le Père Noël vous sortes de son sac, les barrettes tant attendues. ;o)

Vous pouvez également, et si votre PC vous semble suffisamment armé, consulter l'erreur MAX_PATCHES qui vous renseignera sur la façon de diminuer la quantité de patches qui seront créés sur votre map et ainsi descendre la valeur du vismatrix.

Vous venez de compiler votre map, mais malgré les entités de lumière que vous avez pu mettre en place, votre map est beaucoup trop éclairée. Le problème est simple, vous avez du lancer la compilation sans activer le calcul du RAD au moins en mode "normal". C'est en effet le RAD qui prend en charge le calcul de vos lumières, ainsi si vous ne demandez pas à ce qu'il soit activé, le compilateur vous avertira qu'il chargera la lumière maximale par défaut, ainsi votre décor prévu de nuit sera affiché comme en plein jour.

Si cependant vous avez bien activé le calcul du RAD, c'est que votre map à quelque part un leak qui n'a pas empêché la compilation de se terminer ( compilation sous Hammer par exemple ). Il vous faudra alors impérativement boucher ce(s) leak(s) pour que vos beaux effets de lumière puissent enfin prendre leur place dans la map.

Comme nous l'avons vu dans le chapitre sur les lumières, il est possible de donner des effets spéciaux à votre lumière : stroboscopie, bougie...
Si vous mettez trop de lumières différentes au même endroit, vous verrez cette erreur. Pour régler le problème, utilisez moins d'effets lumineux dans votre map.

C'est une erreur d'éclairage, le SKY éclaire, mais la map, particulièrement les armes des joueurs sont noires.
Les causes sont :

• le plancher a été transformé en entité func_wall ou le joueur est bloqué d’une manière ou d’une autre au-dessus du plancher
• mauvais réglages des propriétés du light environment (le PITCH devrait être négatif pour briller VERS LE BAS)
• les blocs de SKY d’un côté de la map sont trop bas
• avec un spot, la valeur du "pitch yaw roll" n'est pas la même que "l’angle" et le "pitch"
• autres

Les models prennent leurs valeurs de luminosité et de couleur de la luminosité et de la couleur du plancher qui se situe au-dessous d'eux. Donc si le plancher est foncé, ou de couleur noire, n'importe quel model au-dessus de lui sera aussi noir. Les avoir sur une entité lumineuse ou sur un bloc avec une texture lumineuse ne changent rien.

Ceci signifie que votre lights.rad est corrompu. Ouvrez lights.rad avec Wordpad ou bloc notes et réparez l’erreur. Si vous ne savez pas comment vous y prendre, ouvrez Valve.rad et effectuer un copier coller dans lights.rad.

Souvent c’est un ascenseur qui occasionne ce problème. Cela provient du fait que l’entité est éclairée seulement par le RAD Bounce. Essayez d'ajouter une lumière directe ou une texture lumineuse pour éclairer directement l'entité.

Il est fort probable que voter fichier *.rmf, *.map ou *.bsp soit corrompu d'une manière ou d’une autre, et ce à cause de la texture Aaatrigger.
La texture AAAtrigger est traitée de manière spécial par le RAD, et se doit d’avoir un lightstyle de 255, ce qui signifie qu’elle ne doit émettre aucune luminosité. Ce qui veut dire clairement que le RAD est supposé les ignorer. Si la texture AAAtrigger est traitée par le rad, c’est très mauvais et ça conduit très certainement à la corruption de votre fichier.

Vérifier donc les propriétés des entités avec la texture Aaatrigger.

Cette nouvelle erreur de compilation est apparue avec le hlcsg v2.5.3 rel Custom Build 1.7 et on n'en connaît pas encore les limites exactes. Ceci pourrait s’expliquer par le fait que vous avez trop de lumières qui peuvent s’allumer et s’éteindre (switchable lights), ou que peut être vous employez des textures lumineuses animées…

Vous placez une entité dans le mode glow alors que cette entité n’accepte pas ce mode. Vérifiez les entités que vous avez placées dans votre map, bloc transformé en func_wall, ou func_door ou toutes autres choses en mode glow.

Cette erreur provient généralement d'un problème de configuration. Pour y remédier, pensez aux fichiers textures chargés dans Hammer " Too many wads "et à bien placer vos compilateurs sur votre disque pour éviter les problèmes de PATH NAMES. Pour plus d'aide je vous demanderai de bien vouloir vous référer à l'erreur "cannot find pts file" car les solutions à apporter à ces deux problemes sont identiques .

Line 5197 is incomplete ( did you place a "inside an entity string"? )

Cette erreur signifie que vous avez rentré un caractère non valide ( ex: , ' % etc...) au moment de nommer une entité ( dans ses paramètres ).

Mais cela peut également provenir d'une face non texturée dans votre map. Celle ci apparaîtra donc avec une couleur blanche sur votre map en mode "textured". Attention, il peut s' agir d'un bloc enfoui sous d'autres blocs et il ne sera pas forcément facile à dénicher.. Cela arrive souvent lorsque l'on utilise un certain nombre de textures que l'on décide de ranger dans un fichier wad perso, il arrive que l'on en oubli et on retire les wads d'origine dans la configuration de Hammer; alors la texture est perdue. Dans ce cas listez le nom de cette texture sur la face , allez la chercher dans les wads d'origine et copiez là dans votre wad perso avec wally.

Pensez à lister tous les problèmes relatifs aux textures à l'aide du ALT-P de Hammer.

Cette erreur rare se produit seulement en mode game/server quand des sprites, des models, des sons, ou des chaînes de caractères (mais pas toutes les chaines de caracteres) sont initialisés et PRECACHED (pris en compte par la mémoire). Si le nom du sprite, du model, du son, ou de toutes autres chaînes de caractères commencent avec un caractère ASCII non imprimable ou si ce nom est de longueur nulle, l'erreur se produira.

Solution: recherchez parmi les entités comme l'env_glow, l'env_sprite, ambient_generic, env_shooter, etc... le nom qui contient un caractère ASCII non imprimable et corrigez-le.

Souvent parce qu'une cycler_entity, un cycler_sprite ou une autre entité utilise un mauvais chemin d’accès. Vous devez employer le chemin d’accès exact avec les majuscules/minuscules ou cela provoquera un crash du jeu.
Le chemin devrait démarrer par model/modelname, et non pas le chemin d’accès entier.
Parfois choisir le model par "parcourir" convient mieux que d’entrer manuellement le chemin d’accès, et parfois c’est le contraire.
En outre un changement d’un model d’origine, comme par exemple un nouveau model de joueur ou d’armes, peut poser ce problème. Réinstallez l’ancien.
Des fois l’erreur apparaît à cause d’un "too many wads".

WorldCraft a des difficultés à exporter votre version du fichier *.map, d'une façon ou d'une autre la fin du fichier que vous avez obtenu a été coupée. Cela signifie qu’il y a une erreur dans voter fichier *.map et qu’à la fin de votre fichier il vous manque un }. Il est aussi probable que la procédure d'exportation ce soit terminé avant la fin. Il a été (ou bien vous avez) inclus des { } ou autres caractères spéciaux dans la chaine de caractères composant le nom d’une de vos entités (ce qui est une très mauvaise idée)

Pour réparer cette erreur :

1- Essayez à nouveau d'exporter votre map de WC/hammer vers un fichier de format *.map et tentez de recompiler
2- Vérifier dans votre map si les entités sont dénommées avec des "" ou des { }
3- Ouvrez votre fichier *.map avec wordpad, allez à la fin du document et essayez d'y ajouter un groupe de }}}}} puis essayez à nouveau de compiler

Vous avez essayé de compiler un fichier *.rmf, au lieu d'un fichier *.map. Ce sont des fichiers de formats différents, même s'ils proviennent de la même map. Assurez-vous que vous exportez votre map vers un fichier *.map et que vous utilisez ce fichier (c:/..../nomdevotremap.map) dans votre outil de compilation.

Ce problème est causé par un mauvais sky environment name. Si les six côtés sont sky_lf, sky_rt, sky_up, etc. vous employez seulement '"sky _" dans le nom du cl_skyname. Laissez toujours tomber n'importe quel Cl _ et les 2 dernières lettres dans un nom de sky en .tga. Un autre exemple: cl_forestrt.tga devrait être employé en tant que "forest" pour le nom de sky.

Pour la plupart d'entre nous un mauvais sky environment name nous laisse avec le sky par défaut. Mais pour quelques mappers, ceci peut causer des "erreurs spéciales"(début du document) comme un mauvais bloc qui n'existe pas, ou un bloc en dehors de la map, ou un mauvais éclairage dans la map, ou même un crash de la map quand le sky entre dans le champ de vision du joueur. Assurez vous donc d’avoir un sky environment name correct.

Les fichiers .wav sont très capricieux. Dans un premier temps, vérifiez le chemin du répertoire vers lequel vous dirigez votre entité. La moindre faute d'ortographe peut conduire à ce que le son ne soit pas joué. ( rajouter l' extension .wav, tout simplement, peut parfois corriger le problème ). Ensuite, s' il s'agit d' un son de votre conception, pensez à respecter le format imposé. En premier lieu, sachez que le fichier .wav ne pourra excéder les 3 minutes, c' est un maximum. Ensuite, il vous faudra respecter le "format" d'enregistrement de votre son, à savoir: 8bits, mono, 11025Hz, de Type PCM . Un éditeur de sons sera alors nécessaire pour convertir votre .wav au bon format (ex: cooledit pro)

Il est possible que cela provienne du fait que vous avez placé la vitesse initiale (initial speed) d'un tracktrain plus haut que 0.

C'est une collision entre deux sons qui peut se produire quand 2 entités essayent de jouer le même son exactement au même moment.

Exemple : 2 trains jouent le même move sound, et les deux trains démarrent à l’aide du même bouton donc ils essayent d'ouvrir le même fichier son au même moment. La seule solution connue est de supprimer le sons des trains... mais ceci est la solution pour l’exemple des deux trains, ensuite à vous d’essayer en fonction des entités concernées par cette erreur.
Pour le SV voir également le "SVC bad" - puisqu’il n’est pas certain que cela puisse être lié au fait que trop d’entités essaient de charger trop de .wav dans le precache du jeu.

Vous pouvez également essayer d’entrer dans la console developer 3 tout en jouant sur la map. Marcher alors dans le trigger_once déclencheur du son. Le rapport d’erreur peut alors donner un élément plus précis sur ce qui est à l’origine du problème.

Cette erreur peut se révéler quand vous testez votre map, et qu’il y a plus de 16 entités qui doivent s'arrêter en même temps, particulièrement s'ils s’agit de func_rotating. Cette erreur provoquée par une "collision" des sons est semblable à "emit_sound: pitch 346". Ceci peut se produire même si vous n'employez aucun bruit - c’est peut être un bug de programmation du moteur de HL. La solution est de faire en sorte que toutes les entités ne s'arrêtent pas en même temps.

Votre .wav fait probablement plus de 3 minutes, choisissez un son plus court ou raccourcissez celui-ci. Cependant, d'autres problèmes inconnu jusqu’ici ont fait apparaître cet erreur.

Hypothèse : la fonction S_Findname() n'a pas pu trouver le nom d’un son.

C'est un bug avec la version 1.1.0.8 de Half-life avec une fonction de commande de voix dans une partie multijoueur. Je crois qu’il serait bon pour vous de télécharger la dernière mise à jour.

Sur quelques cartes sons ceci se produit. Très souvent cette erreur est sans réelle signification et peut-être aisément ignorée, mais si cela cause des problèmes reportez vous à l’erreur "Je ne parviens pas à entendre mes fichiers sons (.wav) ou WARNING: Unable to open sound/C for transfer"

Description: les outils de compilation n' ont pas crée le fichier .pts

Causes: Elles peuvent une nouvelle fois être nombreuses.

Solutions: Vérifiez bien vos paramètres de compilation, (chemin de fichiers incorrectes..), pensez a ne pas charger trop de fichiers textures dans Hammer, je rappelle que se fixer un maximum de 8 fichiers .wad est une bonne chose. Enfin l' erreur peut venir d' un PATH NAME c' est a dire un chemin dirigeant vers vos quatre outils de compilation trop compliqué. Si vous avez installé les outils de compilation sur un autre disque , le compilateur aura du mal à les dénicher, raccourcissez au maximum ce chemin en plaçant les compilateurs à proximité (idéalement, dans le même répertoire que zhlt.exe ). Le compilateur n'apprecie pas beaucoup nom plus les chemins dirigeants vers des répertoires contenant des espaces. ex: c:\program files\zhlt - L'espace entre program et files peut être la cause d' un BAD PATH NAME, c' est assez rare mais encore une fois, c' est arrivé.

Plusieurs choses peuvent vous amener à rencontrer ce type de message. Pour corriger le tir voici quelques conseils:

Vous avez peut être reçus d'autres messages d'erreur durant votre compilation, pensez à vérifier le fichier .log de votre map. Si ce n'est pas le cas vérifiez les points suivants:

• Votre fichier Pack0Pack.pak est peut être corrompu, dans le pire des cas, une réinstallation de Half life s'averera peut être nécessaire.
• Disposez vous des dernières versions du jeu et du Mode pour lequel vous mappez?
• Disposez vous de la dernière version de Hammer ou de Worldcraft? Les vieilles versions contenaient certains bugs qui sont à présent corrigés.
• Disposez vous de la dernière version de ZHLT Compile GUI et de ses compilateurs?
• Tentez une nouvelle compilation, il se peut que le problème disparaisse.
• Avez vous inséré dans votre map, un model ou un sprite "custom" ou issu d'un autre jeu?
• Avez vous installé un patch récemment?, il n'est peut-être pas bon...

Une erreur qui provient le plus souvent d'une entité à laquelle on a associé une cible (target) qui n'existe pas. Vous avez rentré un nom dans le champ target d'une entité mais l'entité appelée n'existe pas ou n'existe plus ( ici c'est start_apc0 ). Utilisez l'outil de Hammer "Entity report" pour lister toutes vos entités et retrouver celle qui est en cause. Mais en général avec un peu de mémoire, on retrouve vite cette entité... Quoique...lol!

Il s'agit d'un problème survenu depuis la version 1.1.0.9 de Half life. Votre fichier packOpak.pak a été mal mis a jour par le patch au moment de recopier les fichiers du "default sky" dans le répertoire environement TGA.
La solution est de télécharger le programme packexplorer ( disponible sur le site ) et d'ouvrir ce fichier pack0pack.pak du répertoire Valve. Vous allez décompresser le contenu du répertoire gfx/env du pack et le placer dans dans le répertoire valve/gfx/env.., ainsi tous les fichiers seront updatés et le problème devrait être résolu.

Si vous avez 5 petites gouttes des points blancs, jaunes, marrons, et rouges; un au milieu, et les quatres autres tournant dans le sens des aiguilles d'une montre. Ceci signifie que vous avez une erreur d'info_node. Un info_node ou un info_node_air a été relié à plus de 256 autres ou moins de 1 autre node. Assurez-vous que votre info_node est relié à au moins un autre node, et les gouttes devraient disparaître.

Une erreur de Hammer(WorldCraft) , vous essayez de faire un bloc de moins de 1*1*1 unité, ce qui est impossible

La seule fois où cette erreur est apparue elle était liée au fait qu’un skin d’arme et/ou de joueur, téléchargé sur le net, avait été installé. La solution est simple il suffit juste de remettre le skin standard officiel.