Bases XML de DayZ : comment s’articulent les fichiers d’économie
Si vous avez déjà ouvert une config de serveur DayZ et vu des tags, entries, types, events et protos lancés sans explication sur un Discord, ce guide est pour vous. Nous parcourons les principaux fichiers XML d’économie un par un, brièvement et clairement, pour que vous voyiez comment ils s’articulent et où agir quand vous voulez « booster » votre loot ou vos zombies. C’est volontairement un tour d’horizon pour débutants - juste assez pour que les grandes idées s’emboîtent.
Fichiers couverts7 XML clésNiveauDébutantObjectifRéglage loot & zombies
Modding de serveur DayZ
Les fichiers XML, étape par étape
11
Parcourez-les dans l’ordre. Chaque fichier fait une seule chose, et l’astuce est de voir comment un nom dans un fichier correspond à un nom dans un autre - c’est cette correspondance qui fait réellement apparaître le loot et les events dans le monde.
01
Comprendre d’abord le vocabulaire
FichierTous
ContrôleModèle mental
Avant de toucher à quoi que ce soit, clarifiez les mots : tags, entries, types, events et protos. Ces cinq termes reviennent sans cesse et sont la raison même pour laquelle les fichiers semblent confus au début. Chacun vit dans un fichier précis et désigne une chose précise ; une fois que vous savez les nommer, vous suivez n’importe quel tutoriel ou fil Discord sans vous perdre.
Le modèle mental qui fait tout s’emboîter est celui-ci : la Central Economy de DayZ est un immense jeu de « chat et attrape ». Un nom défini dans un fichier est référencé par un nom dans un autre, et quand ces noms correspondent, quelque chose apparaît. Gardez cette idée en tête en lisant chaque fichier ci-dessous - vous apprenez surtout où naît chaque nom et où il est utilisé.
02
types.xml - les valeurs économiques de chaque objet
Fichiertypes.xml
ContrôleQuantité, durée de vie, remplissage
Chaque entrée de types.xml appelle un class name. On l’appelle class name parce que les scripts du jeu créent l’objet par classe - l’entrée dit simplement à l’économie que cette classe existe et comment elle doit se comporter. C’est le fichier que la plupart ouvrent en premier pour changer la quantité d’apparition.
Les deux valeurs avec lesquelles l’économie joue le plus sont nominal et min : nominal est la quantité cible que l’économie cherche à maintenir dans le monde, et min est le seuil qui déclenche de nouvelles apparitions. lifetime est la durée, en secondes, pendant laquelle l’objet persiste avant le nettoyage. quantmin et quantmax fixent à quel point un objet est rempli à l’apparition - pour une gourde, par exemple, de zéro à cent pour cent.
Pour « booster » un objet, vous augmentez généralement son nominal et son min. Cela seul dit à l’économie d’en garder davantage en vie dans le monde, sans toucher à aucun autre fichier.
03
cfglimitsdefinition.xml - où naissent les tags, usage et catégories
Fichiercfglimitsdefinition.xml
ContrôleTags / usage / catégories
Tous vos tags, flags usage et catégories « naissent » dans cfglimitsdefinition.xml. C’est leur fichier de définition : dès qu’un nom existe ici, le jeu le reconnaît dans tous les autres fichiers. Vous placez ensuite ces noms sur une entrée types pour dire où et comment cet objet peut apparaître.
Les valeurs usage sont des choses comme Military, Medic, Police, Firefighter, Industrial, Farm, Coast, Town, Village, Hunting, Office, School, Prison et Lunapark. Les catégories et les flags de tier (tier un à tier quatre, area flags, etc.) vivent aussi ici. Le jeu se moque vraiment de leur nom - vous pourriez appeler un usage « hostess snack cake » et cela fonctionnerait, tant que le nom exact est correctement placé sur une entrée d’objet plus loin.
04
mapgroupproto.xml - un proto nomme un objet avec des coordonnées
Fichiermapgroupproto.xml
ContrôleConteneur de loot + tags
Alors, où aboutissent les entrées types dans le monde ? Le proto est la réponse. Un proto nomme un objet - disons un garbage pile - et vous taguez cet objet avec les noms usage et catégorie définis dans votre fichier limits. Le proto porte aussi des coordonnées pour des points de loot individuels mappés autour d’un point central de l’objet.
Un nom de proto peut être ce que vous voulez. Ce qui compte, c’est l’étape suivante : ce nom doit correspondre ailleurs à un nom de position - c’est ce que nous voyons ensuite. Seul, un proto n’est qu’une définition disant « cet objet contient du loot tagué ainsi ».
05
mapgrouppos.xml - faire correspondre les noms de proto aux positions
Fichiermapgrouppos.xml
ContrôleOù se trouvent les conteneurs
mapgrouppos.xml contient les positions. Tant qu’un nom de proto (un mapping) correspond à un nom de pos (une position), ce proto se trouve à cette position en contenant le loot tagué pour ses usages correspondants. C’est le « chat et attrape » en action : le proto est l’attrapeur et le pos l’endroit où il se tient.
En clair, le proto dit « je suis un garbage pile qui contient du loot town et village », et le pos correspondant dit « place ce garbage pile ici ». Si les deux noms sont identiques, le loot apparaît à cet endroit ; si vous tapez mal l’un, rien n’apparaît. À partir de là, tout ce qui est utilisé dans les events suit la même logique de correspondance.
06
events.xml + cfgeventspawns.xml - events et leurs points d’apparition
Fichierevents.xml + cfgeventspawns.xml
ContrôleApparitions dynamiques
events.xml et cfgeventspawns.xml vont ensemble exactement comme proto et pos. Un event a un nom, et ce nom porte un préfixe : Item, Static ou Vehicle. Le nom d’event-spawn correspondant liste les positions de la carte où cet event nommé peut exister.
Dans un event, vous réglez les sorties minimum, maximum et nominal, plus un rayon dans lequel les objets (ou zombies) apparus peuvent se déplacer, et les children - les choses concrètes que l’event produit. Trois champs supplémentaires contrôlent le comportement : safe radius, à quelle distance d’un joueur l’event peut apparaître, distance, à quelle distance d’un autre event, et cleanup, jusqu’où vous devez vous éloigner avant qu’il se désactive.
Quand le child lui-même est la limite, la sortie est contrôlée entre le minimum et le maximum propres à chaque child, avec le nominal global - aucun minimum ou maximum à l’échelle de l’event n’est nécessaire.
07
Events de véhicule et l’angle de direction
Fichierevents.xml (préfixe Vehicle)
ContrôleVoitures, mélange, orientation
Un event à préfixe Vehicle fonctionne pareil - le nom d’event correspond à un nom d’event-spawn, donc l’event va à ces positions. La nouveauté est la valeur « a= », la direction dans laquelle le véhicule fait face. Le capot pointe selon cet angle : 0 ou 360 est le nord, 180 le sud, et un peu de calcul mental donne n’importe quel cap sur le cercle.
Les events de véhicule utilisent généralement une limite « mixed ». Au lieu de forcer chaque child listé à chaque position exacte (ce qui entasserait les voitures), vous dites à l’économie de garder un total global entre un min et un max autour du nominal - par exemple un total de 11 à 15 véhicules, visant environ 13, avec au plus un à trois de chaque type de child dans le mélange.
Le reste se comporte comme tout event : lifetime régit la durée d’un véhicule, et les mêmes règles de safe radius, distance et cleanup s’appliquent. Quand un véhicule est ruiné, l’event le retire et en fait apparaître un neuf à la rotation suivante.
08
Les events d’infectés parlent à un fichier territory
Fichierevents.xml + territory
ContrôleRépartition & nombre de zombies
Un event d’infectés (zombies) parle à un fichier d’environnement appelé territory, qui définit où appartient ce groupe d’infectés. Le côté territory est un sujet plus profond qui mérite son propre tutoriel, mais les bases suffisent pour faire des changements.
Pour simplement booster les zombies, augmentez les sorties minimum et nominal de l’event d’infectés - vous avez rarement besoin de toucher au maximum. Vous pouvez aussi mélanger différents children d’infectés dans d’autres events pour les répartir sur la carte là où vous en voulez plus.
09
cfgrandompresets.xml - pools de loot cargo et attachment
Fichiercfgrandompresets.xml
ContrôleCe qui apparaît dans/sur les objets
Les random presets sont l’intermédiaire entre types.xml et les spawnable types. Un preset crée un pool de loot cargo ou attachment nommé : une liste de types ou de classes, chacun avec une hit chance. Quand cette chance se déclenche, un des children du pool est choisi.
C’est ainsi que vous obtenez de la variété dans ou sur un objet - par exemple un preset cargo qui remplit un conteneur, ou un preset attachment qui met un chapeau ou un sac à dos sur un zombie. Le preset ne définit que le pool ; c’est le spawnable type, ensuite, qui dit à un objet de l’utiliser réellement.
10
cfgspawnabletypes.xml - donner leur équipement aux objets
Fichiercfgspawnabletypes.xml
ContrôleAttachments & cargo à l’apparition
cfgspawnabletypes.xml est ce qui dit à un type d’avoir d’autres types attachés à lui ou contenus en lui. C’est le consommateur des random presets définis juste avant : un spawnable type pointe par nom vers un preset cargo ou attachment, et les hit chances du preset décident alors ce qui apparaît réellement.
En bref, types.xml dit qu’un objet existe, le random preset définit un pool d’extras possibles, et le spawnable type relie les deux pour qu’un objet fraîchement apparu arrive avec le bon cargo et les bons attachments.
11
globals.xml - interrupteurs à l’échelle du serveur
Fichierglobals.xml
ContrôlePlafond zombies, idle, volume de loot
globals.xml contient les interrupteurs à l’échelle du serveur, et il est plus puissant qu’il n’y paraît. Tout en bas se trouve le compteur global d’infectés - augmentez-le ou baissez-le pour fixer l’IA maximale autorisée. Le vanilla se situe quelque part entre 1000 et 1200 ; dans le build source il a été baissé à 850. À côté, vous trouverez l’animal count et la vitesse de nettoyage d’un cadavre.
Une paire de valeurs clé sont les réglages idle. Mettez les deux valeurs idle à zéro et votre économie continue de tourner même sans personne en ligne, pour que loot et events restent frais sur un serveur 24/7. D’autres interrupteurs ici contrôlent le nombre de pièces de loot apparaissant au départ, et permettent d’activer ou non des systèmes comme wet, world et tents.
Ce n’est que le tour d’horizon pour débutants - il y a plus de fichiers et des vidéos bien plus poussées sur chacun. Mais savoir comment ces fichiers clés se référencent suffit pour commencer à régler en sécurité le loot et les zombies de votre serveur.
Commencez dans types.xml et augmentez le nominal et le min de l’objet souhaité. nominal est la quantité cible que l’économie maintient dans le monde et min est le seuil qui déclenche de nouvelles apparitions.
Comment ajouter plus de zombies ?
Pour un plafond global, augmentez le compteur d’infectés dans globals.xml. Pour rendre une zone précise plus animée, augmentez le minimum et le nominal de l’event d’infectés concerné dans events.xml - vous n’avez généralement pas besoin de toucher au maximum.
Pourquoi rien n’apparaît après ma modification ?
Presque toujours une non-correspondance de noms. Un nom de proto doit correspondre exactement à un nom de pos, et un nom d’event exactement à un nom d’event-spawn. Vérifiez l’orthographe et la casse des deux côtés.
Quelle est la différence entre un random preset et un spawnable type ?
Un random preset (cfgrandompresets.xml) définit un pool nommé de cargo ou d’attachments possibles avec des hit chances. Un spawnable type (cfgspawnabletypes.xml) dit à un objet réel d’utiliser ce pool - le preset est donc l’intermédiaire entre types.xml et ce qu’un objet porte à l’apparition.
Comment garder l’économie active sans joueurs en ligne ?
Dans globals.xml, mettez les deux valeurs idle à zéro. L’économie tourne alors en continu, pour qu’un serveur 24/7 reste approvisionné en loot et events frais.