Partage
  • Partager sur Facebook
  • Partager sur Twitter

[HL1] Annexe : les erreurs de compilation

Celle de la V2 du SDZ.

Anonyme
28 janvier 2006 à 14:20:15

Edge with both face id's already filled.



Le seul cas où ceci est apparu, c'était à cause d’un problème de vertex sur un bloc. Voir l’erreur "MAXPOINTS".
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 14:24:03

Des points verts "volent" autour de mon monstre/joueur ou des points jaunes "volent" autour de mon model.



Le problème provient du fait que le monstre est coincé dans un mur ou est trop près du mur ou d'un bloc. Quand un monstre/joueur/model se coince dans un mur, le moteur crée ces points volants pour attirer votre attention, ainsi vous visualiser votre erreur. La solution consiste simplement à le déplacer hors du mur et ce sera bon.
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 14:28:29

MakeNodePortal:new portal was clipped away from node@(coordonnées).



Ceci indique qu’un bloc est invalide. Vous pouvez trouver ce bloc grâce aux coordonnées données dans le log. Ensuite vous le supprimez et vous le recréez. Habituellement cette erreur provient du fait que vous utilisez les anciens outils de compilation qbsp, qcsg etc... Si tel est le cas installez les nouveaux outils de compilation ZHLT et le problème disparaîtra ou donnera un nom d’erreur plus détaillé. Souvent la nouvelle erreur sera "Malformed face normal"
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 14:34:17

SubdivideFace: didn't split the 4-sided polygon @(coordinates).



Le seul cas où cette erreur est apparue c’était du aux murs qui entouraient la map (aucune idée de la cause précise de cette erreur de bsp).
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 14:39:45

Max_leaf_faces.



Description: Erreur comparable: MAX PATCHES. Le compilateur (VIS) ne parvient pas à calculer les faces d'un de vos blocs.

Causes: Avez vous carvé un bloc de forme complexe? le carving sur, ou a l' aide d' un cylindre ( par exemple ) est bien souvent la cause de cette erreur.

Solutions: Utilisez la commande ALT-P de Hammer pour détecter le bloc en cause, et s' il ne le détecte pas cherchez ce bloc carvé et détruisez le pour le reconstruire d' une manière plus simple.
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 14:41:23

Alloblock:full



Voilà une erreur dont il est bien difficile de trouver les causes! ( je sens déja vos tremblements!! lol ) . Le problème est que trop de choses peuvent vous conduire à ce message d'erreur, pour résumer je dirai que les compilateurs ne parviennent pas à calculer votre map. Quelles peuvent donc être les différentes raisons de cette incapacité? Et bien, en premier lieu, une configuration matérielle quelque peu dépassée, un minimum de 128 Mo de ram est fortement conseillée pour la compilation. Le processeur de votre machine est très sollicité pour ce travail, il faut donc parfois investir pour devenir un bon mappeur!! d'autre-part pensez en cas de soucis de ce genre, à fermer les autres applications qui pourraient occuper un certain pourcentage de vos ressources, les programmes qui travaillent en tâches de fond tels que les anti-virus sont bien connus pour ça.

Si votre configuration matérielle vous semble irréprochable, il va alors falloir vous concentrer sur votre map et essayer de trouver à quels endroits vous auriez pu commettre certains excès! Vous pourrez alors vous diriger vers différentes alternatives. Tout d'abord, tel que l'erreur "leaf saw into leaf" pourrait vous le signaler, une mauvaise architecture entraînera parfois de devoir calculer une trop grande partie de la map au même moment et les compilateurs ne sont pas trop "chauds" pour ça! . Vérifiez que les chemins des répertoires conduisant à vos compilateurs ne soient pas trop compliqués (PATHNAMES) , n'avez vous pas chargé trop de fichiers textures dans Hammer?, Les chemins conduisant à vos fichiers .WAV ou .SPR sont ils correctes?

Pour résumer, à un certain moment, vous avez du sans le savoir, rendre la tâche des compilateurs trop ardue. Par expérience, le problème survient souvent lors de l'utilisation de ce que j'appelle le bloc "noob" ! à savoir une vilaine skybox entourant votre map pour éviter les "trous" si bien connus sous leur nom anglais les "leaks" et pour éviter de devoir les corriger. Gardez toujours en tête qu'une skybox aura en effet la capacité de corriger les erreurs de leak, mais les compilateurs auront pour but de calculer toute la map et ainsi de calculer les espaces de vides créés tout autour de celle-ci. Cette méthode est à bannir de toute urgence!

  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 14:42:43

Error: Too many entities.



Description: Vous avez créé trop d'entités visibles en un même endroit.

Causes: Il existe deux causes à ce problème. La première est simple, vous avez choisi de compiler sans activer le VIS, le seconde qui est la plus courante vient d' une utilisation abusive d' entités en un même endroit .

Solutions: Vous l' aurez compris, il va falloir renoncer à certaines entités. Le cas le plus recensé est l'emploi abusif de l'entité func_wall parfois utilisée sur un trop grand nombre de blocs.

  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 14:43:56

ReadSurfs (line 99416):32189>g_numplanes --ou-- Max_map_planes.



Description: Vous avez dépassé le nombre de faces autorisées.

Causes: l'emploi abusif de blocs ou de blocs de forme trop complexe.

Solutions: La première chose à faire est de tenter une nouvelle compilation, il arrive que cette erreur disparaisse alors. Dans le cas contraire, il va falloir que vous conceviez certaines parties complexes de la map à l' aide de blocs de formes plus simples et plus mathématiques. L' emploi de blocs à plus de 32 faces conduit très souvent à ce message d' erreur, recherchez donc quel bloc peut être en cause et supprimez le pour le remplacer par un bloc plus simple. Les cylindres sont bien évidement les plus souvent concernés. Si vous pensez ne pas avoir utilisé trop de blocs de ce type, il peut tout simplement s'agir d' une trop grande quantité de blocs, il vous faudra alors simplifier votre map et vous débarrasser de certains détails :( aie aie aie ça c' est très dur!!
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 14:46:28

Exceeded MAX_PATCHES.



Quand la compilation en arrive au calcul de la lumière (en fonction des entités de lumière placées dans la map ) c'est le RAD qui se retrousse les manches. Il est en effet responsable de cette partie si importante de la compilation. Du reste vous aurez remarqué que si vous compilez sans avoir activé le RAD, un "Défault light level" sera alors automatiquement appliqué par le compilateur pour ne pas vous plonger dans le noir absolu. Ce qui à tendance à en étonner plus d'un la première fois , car les effets de lumière qui sont si importants sont réduis à néant.

Le RAD est à la base de pas mal de problèmes de compilation, car la lumière est calculée, en tenant compte de l'architecture générale de la map. En effet ce précieux outil a pour habitude, pour effectuer son calcul, de prendre toutes les faces visibles durant le jeu sous Half-life et de les diviser en petites sections que l'on appelle des PATCHES. Il va donc créer des petites pièces et se servir des différentes textures qui la composent pour effectuer de longs calculs. Mais ce calculateur, à une limite de 65535 patches qu'il ne peut dépasser. La texture appliquée sur un bloc étant sa référence principale, utiliser une texture de petite taille sur un bloc de grande taille aura pour incidence d'agrandir ce que l'on appelle le "lightmap" que l'on pourrait définir comme les informations de lumière de la map.

Ainsi, les erreurs de ce type peuvent provenir de différentes choses, comme par exemple l'utilisation du "noob block" autrement dit une "skybox" pour venir à bout de problèmes de leaks. Car les patches créés par le RAD en seront d'autant plus grands . Le calcul du RAD et donc de la lumière finira donc parfois par atteindre ses limites et par vous demander de lui simplifier la tache. Un autre exemple de ce qui peut provoquer cette erreur, les maps de trop grande taille, pour les même raisons vous vous en doutez.

Les solutions sont donc relativement simples à comprendre: vous séparer de votre skybox est inévitable et si vous n'avez pas commis cette erreur, vous aurez certainement commis la seconde, une map beaucoup trop grande, ou en tout cas, des sections de map de trop grande taille. Vous savez donc de quoi il en retourne! = Allez allez, au boulot!! :D Pensez à bien structurer votre map en "pièces" pour diminuer la visibilité (chapitre Optimisation )
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 14:59:12

Z_malloc failed on allocation of xxx bytes --ou-- D_SCAlloc: bad cache size 0.



Un problème d’insuffisante de mémoire ou d’allocation de mémoire. Les causes possibles sont très nombreuses, y compris le manque de RAM et également l’erreur "texture axis perpendicular to the face". Essayez de regarder les autres erreurs de mémoire de cette page.
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 15:00:22

SVC_BAD --ou-- "500 overflow temporary ents!" --ou- FSB_ALLOWOVERFLOW.



Comme Precache, c'est habituellement un problème de mémoire. Cette erreur est habituellement provoquée par le fait que trop d'entités sont appelées par un model (comme des breakables et des pushables). La solution principale est la réduction de ces dernières.

Une autre cause du SVC_BAD, la compilation avec le flag -onlyents après avoir changé la géométrie générale de la map. En outre le problème de SVC peut se produire en raison de diverses combinaisons d’entités qui sont ensemble sur la map, il peut être provoqué par les ascenseurs qui sont placés en position up quand ils ont certains flags de cochés.
La raison la plus courante du SVC_BAD c’est une mauvaise compilation où une entité basée sur un bloc qui n'a pas été correctement compilée, ainsi ceci peut même être provoqué par une entité basée sur un bloc de forme invalide. Le SVC est particulièrement dur à cerner et à corriger. Il est également possible que les autres erreurs comme le Precache posent ces problèmes.
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 15:04:14

HOST ERROR: PF_precache_model_l:'sprites/spritename' overflow --ou-- No Precache --ou-- WARNING: missing precache: --ou-- error running precache --ou-- Host_Error: No player.mdl precache --ou-- host error: precaching overflow on player models --ou-- HOST ERROR: PF_precache_model_1:'models/modelname.mdl' overflow --ou-- autres.




Precache est un problème de mémoire. C’est souvent du à un mauvais nom ou un mauvais chemin d’accès pour un sprite, un model, ou un fichier wav. Mais il se peut également que vous ayez de trop grand ou une trop grosse quantité de sprites, de models (MAX_MAP_MODELS: 400), de fichiers wav (limite < 3min) ou d'entités (~0.5M) ce qui contribue à un dépassement de la mémoire qui leurs est réservée (voir également l’erreur "SVC bad")
De temps en temps cette erreur se produit quand vous employez un model/sprite corrompu ou non standard. En utilisant les préfabs que vous téléchargez vous pouvez aussi retrouver cette erreur. Parfois ce sera à cause du "too many wads" que vous retrouverez ce problème de precache ou encore si vous avez un bloc texturé avec la texture d'AAAtrigger visible dans votre map. Les raisons de ces problèmes sont aussi diverses que variées…


Il est probable que cette erreur surviennent lorsqu'il y ait trop d'entités-blocs.
Il semble être préférable de ne surtout pas dépasser les 75% de models dans la map. Une marge est ainsi disponible pour l'utilisation de mods-serveur comme AMX, par exemple, qui ajoute des entités dans les maps.

Merci à MisterJ pour le complément.


  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 15:06:18

Malloc Block: Full.



La seule fois ou cette erreur est apparue dans un log il s’agissait en fait d’un "leak"
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 15:08:29

MAX_MAP_MIPTEX (Zoner's Compiling Tools) --ou-- ReadSurfs (line ReadSurfs: 990 > numtexinfo.



Bien que les ZHLT vous recommande de fusionner ou d’enlever les wads inutilisés, voici une autre solution.
Utilisez juste le flag "-texdata" dans les lignes de commandes du HLCSG pour augmenter la mémoire utilisée pour les textures. Normalement elle est placée à 4096 (en comparaison le QCSG est à 2048), mais vous pouvez entrer une valeur d’au moins 8192.
Quand vous entrerez une plus grande valeur pour votre -textdata, regardez le log de votre compilation et il vous indiquera combien de mémoire, en plus des 4096 initials, votre HLCSG emploie réellement.

Les limites pour - texdata :
Vous pouvez entrez une valeur aussi grande que celle qu’accepte la mémoire des cartes vidéo que vous comptez utilisez (par exemple pour les anciennes Voodoo 2 le -textdata peut aller jusqu'à 8 Mo (8192) ou 12 Mo) Si vous êtes sur que votre map sera seulement jouée en LAN où chacun des joueurs disposera de cartes vidéo de 64Mo, alors vous pouvez placer le -texdata à 64000 !!! Mais si vous entrez une valeur si grande et que vous décidez de distribuer votre map, vous perdrez les joueurs qui joue en mode software (-textdata 4096) et ceux qui dispose d’une carte graphique plus ancienne (-textdata 8192)
Plus la valeur de votre -texdata sera grande, moins il y aura de personnes qui pourront jouer sur votre map.

  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 15:09:37

MAX_MAP_MODELS



L'erreur max_map_models apparaît quand vous avez dépassé le nombre maximum d’entités blocs dans votre map. Ceci peut être la somme totale d'entités blocs ou d'une entité spécifique. Ainsi ou vous avez un trop grand nombre d'un même type d'entité bloc ou vous avez dépassé le nombre d'entités blocs maximum dans le jeu (comme par exemple si tous les éléments de votre map sont des entités func_xxxxx).
Chaque model de joueur, chaque grenade, arme, etc. compte dans le MAX_MAP_MODELS. La somme totale des models est dynamique et varie en cours de partie quand de nouveaux models apparaissent ou disparaissent du champ de vision du joueur. Vous devez simplement vous assurer de garder une petite marge de manoeuvre.
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 15:10:28

MAXPOINTS



La plupart des programmes d’édition de map vous permettent de créer des blocs qui ne peuvent pas exister dans le moteur du jeu en raison des limitations des compilateur et/ou du moteur de jeu lui-même.
Comme par exemple, si vous créez avec WC/Hammer une salle avec un cylindre de 32 faces au milieu, WC/Hammer vous laissera le faire, mais si vous essayez alors de compiler, vous obtenez une erreur de MAXPOINTS.
Le cylindre possède alors deux faces avec 32 côtés, ce qui est au-dessus de la limite de MAXPOINTS (28) fixé par les outils de compilation.
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 15:11:53

MAX_PORTALS_ON_LEAF



Ceci est normalement provoqué quand on a de grandes salles qui sont reliées à beaucoup d'autres alvéoles, ou d'autres formes semblables. Alternativement il est provoqué par un bloc invalide que vous devriez trouver facilement en faisant alt+p.

La grande salle principale est un leaf, chaque alvéole correspond aussi à un leaf, mais l’ensemble forme un grand leaf qui joint tous les autres petits pour un total de 32 portals.
Le max_portals_on_leaf est de 256 dans half-life, ainsi ce problème est tout à fait rare et habituellement c’est un effet secondaire obtenu à cause d’un bloc invalide dans la map.

  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 15:13:09

MAX_TRI_TRIS --ou-- MAX_TRI_POINTS --ou-- MAX_TRI_EDGES



Une erreur causée par une ancienne version du RAD des ZHLT.
Solution, téléchargez la dernière version des ZHLT.
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 15:15:53

Memory allocation failure



Description: Le programme ne parvient pas à allouer les blocs de mémoire comme il le veut. Les causes probables de cette erreur sont (par ordre de probabilité):

  • ne compilez pas avec le compilateur intégrer de WC/Hammer (F9 -run). Cela provoque une trop grosse utilisation de votre mémoire RAM. Utilisez un autre programme de compilation comme Batch compiler ou ZHLT Compile Gui
  • la partition contenant votre dossier mapping est pleine (effectuez un nettoyage de votre disque dur, vider votre corbeille, effacez vos fichiers inutilisés, vider votre dossier Temp et votre dossier Temporary internet files)
  • la taille de votre partition est trop petite par rapport aux besoins du jeu
  • votre disque dur est trop fragmenté (donc defragmentez-le)
  • corruption de masse (rebootez votre PC et réessayez de nouveau). Vérifiez si vous n’avez pas de virus
  • Il est possible que ce soit du à l’insertion dans votre map d’un préfab corrompu
  • Enlevez votre skybox si vous en avez une et optimisez votre map pour avoir des zones plus petites
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 15:17:23

No free edicts --ou-- NUM_FOR_EDICT: bad pointer



Chaque entité dans le jeu utilise un slot d'edict. Si le jeu manque de slots d'edict alors vous obtenez un message d’erreur "no free edicts". La solution est de réduire le nombre d'entités dans votre map. Les mods en single player (SP) peuvent avoir un nombre différent d'edicts que les mods en multiplayer (MP), en raison du nombre d'entités déjà occupées par l’emplacement de chaque départ de joueur, des sprites et des models nécessaires au bon déroulement de vote map (ex : des armes au sol dans une map fy_ pour CS).
Le rapport général d’HL nous a fixé les limites suivantes :

  • SP entre 900 et 1024
  • MP=entre 1365 et 2048 (cela varie selon votre mod)
Cependant, dans une petite map avec peu d'entités, l'erreur peut également se produire si vous avez utilisé la même entité trop souvent.
En outre l’erreur " bad pointer " peut signifier que le bsp a été corrompu, ou même qu’un fichier dll est corrompu. Examinez d'autres maps pour voir si cette erreur se produit toujours, si ce n’est pas le cas essayez d’obtenir une autre version de votre .bsp. Si cette erreur persiste seulement avec cette map, c'est probablement à cause d’un trop grand nombre d'entités.
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 15:18:24

Node graph out of date, rebuilding



Le node graph est ce qui commande l’IA. C'est tous les itinéraires entre vos entités d'info_node. Chaque fois que vous changez de map ils doivent être reconstruit (ce que fait HL). Plus il y a de nodes et plus il sont complexes, plus ce sera long. Les fichiers pour le graph sont dans le dossier maps/graphs et doivent être distribué avec les maps sauf s’il s’agit d’une map SP.
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 15:25:08

Short ### surfaces



Semblable aux erreurs max leaf faces ou ReadSurfs (line xxxxx): 32189 > g_numplanes, dans celle-ci vous manquez de faces planes pour votre map. L'une des fois ou cette erreur est apparu, elle a été provoquée par un leak en mode software, bien qu'elle puisse également être causée par des textures trop rétrécies faisant ainsi grimpés les r_speeds. (Cependant, ce n'est pas seulement une erreur de leak, c'est une erreur de trop de surfaces et cela peut être provoqué par d'autres choses!)

Voir également : skybox.
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 15:26:39

Short ### edges



Comme l'erreur de "Maxpoints", dans celle-ci vous manquez d’arrêtes. Ceci est probablement provoqué par le mode software et de mauvais r_speeds (wpoly >800), ou peut-être en faisant des blocs complexes comme des cylindres qui s’entrecroisent.
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
28 janvier 2006 à 15:58:00

Vismatrix too big



Ceci est encore un problème de mémoire. La consommation de mémoire du vismatrix est trop importante par rapport à la mémoire dont dispose votre PC.

Quelques solutions envisageables :

1. Essayez d’installer plus de RAM sur votre PC.
2. Compilez votre map sur un ordinateur qui dispose de plus de RAM.
3. Utilisez une plus grande valeur de -chop (valeur par défaut : 64) pour avoir un vismatrix plus petit, sacrifiant la qualité finale de votre map en attendant de pouvoir la compiler sur un ordinateur plus puissant.
4. Utilisez un -bounce à 0 (aucun rebond de lumière) ce qui sautera l'étape du vismatrix et donnera juste un l'éclairage direct. Cela utilisera beaucoup moins de RAM mais le calcul d’éclairage sera vraiment approximatif et il n’y aura pas un bon rendu par rapport à une map compilée avec un bounce plus élevé.
5. Utilisez le -sparse du HLRAD pour utiliser moins de mémoire.

Voir également : skybox.
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
12 février 2006 à 11:04:32

Lors de la compilation le VIS calcule très lentement



Il faut savoir que plus votre machine sera armée de mémoire, moins longue devra paraître la compilation. Néanmoins il peut arriver sur certaines compilations et ce malgré une machine du dernier cri, que le travail du VIS vous paraisse interminable. Ce problème vient inéluctablement de la conception même de votre map. Le VIS intervient sur les distances et la quantité de détails que saura voir le joueur en un même point . Il va s'en dire que si votre map est de grande envergure et que vous n'avez pas pensé à la "cloisonner" pour limiter cette visibilité, le VIS aura un calcul beaucoup plus compliqué à effectuer. Dans ce cas précis il lui arrivera même de planter la compilation. Relisez bien le chapitre sur l'Optimisation )

Bien penser l'architecture de sa map est la seule solution pour augmenter la vitesse de calcul du VIS. La première map d'un néo-mappeur aura quasiment toujours les défauts cités à l'instant mais vous verrez que l'habitude de séparer les différentes partie de la map, pour diminuer la visibilité, deviendra vite chez vous un réflexe. J'allais presque oublier, mais il est bien évidement, encore une fois déconseillé d'avoir recours à une skybox pour vous séparer de vos leaks. Celle ci est l'ennemie numéro un du VIS, imaginez la taille de la pièce que vous pourriez lui donner à calculer...ça calme tout de suite!

Pour finir, il faut noter qu'un minimum de 256 Mo de ram sur votre machine est vivement conseillé pour les maps les plus complexes.

  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
12 février 2006 à 11:05:29

Leaf portal saw into leaf




A la base cette erreur provient d'un bloc servant de sol dans un coin de la map qui a mal été vertéxé et qui à généralement pour effet de faire calculer une trop grande partie de la map au VIS. C'est les r_speeds qui en prennent un sale coup !!!

Sachez qu'avant de vous creuser les méninges, vous pouvez trouver ce message d'erreur dans le fichier .log de votre compilation, cependant, cette dernière ne bloquera pas forcement et il vous faudra alors tester votre map, pour voir si elle a une réelle incidence.
Si vos r_speeds vous semblent convenables, oubliez ce message. Vous pouvez également compiler en mode HL SOLO et exécuter ensuite via la console la commande suivante: gl_wireframe 1 ou gl_wireframe 2 en mode openGL . Vous pourrez ainsi contempler les différentes parties de la map qui sont calculées en temps réel en fonction de l'endroit ou vous êtes situés. Si derrière un mur vous voyez que toute la map est calculée, il y aura du boulot sur la planche...

La première chose à faire, à réception de cette erreur est de tenter une compilation avec le calcul du VIS en mode "FULL" , le problème aura alors des chances de disparaître.
Si cela n'a rien changé, à l'aide des coordonnées accompagnant votre message d'erreur, retrouvez le bloc ( ou les jonctions de blocs ) et transformez ce ou ces derniers en func_wall, car ceux-ci n'entrent pas en compte dans le calcul du VIS.
Vous pouvez encore poser des blocs clips tout autour de vos blocs défectueux, cela marche certaines fois.
Enfin si rien n'y fait, il vous faudra reconcevoir d'une façon différente le quartier qui pose problème de telle manière que le VIS n'ait pas à calculer de trop grandes surfaces.

  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
12 février 2006 à 11:06:49

Portal file xxxxx does not exist...




Description: le fichier .prt de votre map n'a pas été créé et la compilation s' arrête.

Causes: Les raisons peuvent être diverses et il est parfois difficile de les trouver.

Solutions: En premier lieu, consultez le fichier .log résultant de votre compilation, si l' erreur vous est clairement expliquée, des coordonnées y seront également notifiées et il vous sera alors aisé de fixer cette erreur. Dans le cas contraire, il vous faudra partir à la chasse!! Faites donc un tour vers l' erreur TOKEN TOO LARGE, à peu près similaire, puis vérifiez le nom du sky, vos fichiers textures, et dans le pire des cas, une réinstallation des outils de compilation s'averera nécessaire. Ça c' est déjà vu!!

  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
12 février 2006 à 11:08:01

LoadPortals: failed to read header ou LoadPortals: couldn't read.... ou LoadPortals: not a portal file ou LoadPortals: reading portal.... ou LoadPortals: portal.... has too many points




Ce message peut arriver lors de la compilation: " an error occured while loading the xxxxx.prt file "
Le fichier .prt issu de votre compilation n'a pas été crée ou il a mal eté crée. ( il ne sera peut être pas crée du tout en cas de Leak ) . Il se peut que votre map soit trop complexe et que le BSP ne parvienne pas a créer ce fichier.
Le mieux alors est d'être sur de posséder la dernière version de vos outils de compilation, de tenter une nouvelle compilation et dans le pire des cas d'essayer de simplifier votre map.

  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
12 février 2006 à 11:09:00

Mon CIEL devient invisible quand je suis dans un func_water



Ceci peut se produire quand vous n'avez pas fait une compilation finale avec le RAD et le VIS -full, ou c’est peut-être parce que vous n’avez pas les bons drivers pour votre carte graphique.
  • Partager sur Facebook
  • Partager sur Twitter
Anonyme
12 février 2006 à 11:17:12

Lors de la compilation le RAD calcule très lentement et bloque parfois au moment du "MakeScale"




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.

  • Partager sur Facebook
  • Partager sur Twitter