![Day[Z] Titan Launcher logo](/assets/img/logo2.webp?v=1781090027){kind=logo}
Day[Z] Titan Launcher
Se já abriste uma config de servidor DayZ e viste tags, entries, types, events e protos atirados sem explicação num Discord, este guia é para ti. Percorremos os principais ficheiros XML de economia um a um, de forma breve e clara, para veres como se ligam e onde mexer quando queres «boostar» o teu loot ou os zombies. É propositadamente uma visão geral para iniciantes - apenas o suficiente para as grandes ideias encaixarem.
Percorre-os por ordem. Cada ficheiro faz uma só coisa, e o truque é ver como um nome num ficheiro corresponde a um nome noutro - é essa correspondência que faz o loot e os events aparecerem realmente no mundo.
Antes de mexer em seja o que for, esclarece as palavras: tags, entries, types, events e protos. Estes cinco termos surgem constantemente e são a razão de os ficheiros parecerem confusos ao início. Cada um vive num ficheiro específico e refere-se a uma coisa específica; assim que os souberes nomear, segues qualquer tutorial ou tópico de Discord sem te perderes.
O modelo mental que faz tudo o resto encaixar é este: a Central Economy do DayZ é um enorme jogo de «apanhada». Um nome definido num ficheiro é referenciado por um nome noutro, e quando esses nomes coincidem, algo aparece. Mantém esta ideia na cabeça ao ler cada ficheiro abaixo - basicamente só estás a aprender onde nasce cada nome e onde é usado.
Cada entrada em types.xml chama um class name. Chama-se class name porque os scripts do jogo criam o item por classe - a entrada apenas diz à economia que esta classe existe e como se deve comportar. É o ficheiro que a maioria abre primeiro para mudar quanto algo aparece.
Os dois valores com que a economia mais joga são nominal e min: nominal é a quantidade-alvo que a economia tenta manter no mundo, e min é o limite mínimo que dispara novos spawns. lifetime é quanto tempo, em segundos, o item persiste antes da limpeza. quantmin e quantmax definem quão cheio um item está ao aparecer - para um cantil, por exemplo, de zero a cem por cento.
Para «boostar» um item, normalmente aumentas o seu nominal e min. Só isso diz à economia para manter mais dele vivo no mundo, sem tocar em qualquer outro ficheiro.
Todas as tuas tags, flags usage e categorias «nascem» em cfglimitsdefinition.xml. É o ficheiro de definição delas: assim que um nome existe aqui, o jogo reconhece-o em todos os outros ficheiros. Depois colocas esses nomes numa entrada types para dizer onde e como esse item pode aparecer.
Os valores usage são coisas como Military, Medic, Police, Firefighter, Industrial, Farm, Coast, Town, Village, Hunting, Office, School, Prison e Lunapark. As categorias e flags de tier (tier um a tier quatro, area flags, etc.) também vivem aqui. O jogo realmente não quer saber como lhes chamas - podias chamar a uma usage «hostess snack cake» e funcionaria, desde que o nome exato esteja corretamente colocado numa entrada de item mais à frente.
Então, onde vão parar as entradas type no mundo? O proto é a resposta. Um proto nomeia um item - digamos um garbage pile - e tu marcas esse item com os nomes usage e categoria que definiste no teu ficheiro limits. O proto também carrega coordenadas para pontos de loot individuais mapeados em torno de um ponto central do item.
Um nome de proto pode ser o que quiseres. O que importa é o passo seguinte: esse nome tem de corresponder a um nome de posição noutro lado - é o que vemos a seguir. Por si só, um proto é apenas uma definição que diz «este objeto guarda loot marcado assim».
mapgrouppos.xml guarda as posições. Desde que um nome de proto (um mapping) corresponda a um nome de pos (uma posição), esse proto fica nessa posição a guardar o loot marcado para as suas usages correspondentes. É a «apanhada» em ação: o proto é o apanhador e o pos o sítio onde ele fica.
Em termos simples, o proto diz «sou um garbage pile que guarda loot town e village», e o pos correspondente diz «coloca esse garbage pile aqui». Se os dois nomes forem idênticos, o loot aparece nesse ponto; se erras um, nada aparece. Daqui em diante, tudo o que é usado em events segue a mesma lógica de correspondência.
events.xml e cfgeventspawns.xml andam juntos tal como proto e pos. Um event tem um nome, e esse nome carrega um prefixo: Item, Static ou Vehicle. O nome de event-spawn correspondente lista as posições do mapa onde esse event nomeado pode existir.
Dentro de um event defines as saídas minimum, maximum e nominal, mais um raio dentro do qual os objetos (ou zombies) que aparecem podem andar, e os children - as coisas concretas que o event produz. Três campos extra controlam o comportamento: safe radius, quão perto de um jogador o event pode aparecer, distance, quão longe tem de estar de outro event, e cleanup, quão longe tens de te afastar antes de desativar.
Quando o próprio child é o limite, a saída é controlada entre o minimum e o maximum de cada child em conjunto com o nominal geral - não é preciso um minimum ou maximum à escala do event.
Um event com prefixo Vehicle funciona do mesmo modo - o nome do event corresponde a um nome de event-spawn, por isso o event vai para essas posições. A novidade é o valor «a=», a direção para a qual o veículo aponta. O capô aponta segundo esse ângulo: 0 ou 360 é norte, 180 é sul, e um pouco de cálculo mental dá qualquer rumo no círculo.
Os events de veículo usam normalmente um limite «mixed». Em vez de forçar cada child listado em cada posição exata (o que empilharia carros), dizes à economia para manter um total geral entre um min e um max à volta do nominal - por exemplo um total de 11 a 15 veículos, com alvo em cerca de 13, e no máximo um a três de cada tipo de child na mistura.
O resto comporta-se como qualquer event: lifetime rege quanto tempo um veículo dura, e aplicam-se as mesmas regras de safe radius, distance e cleanup. Quando um veículo fica destruído, o event remove-o e faz aparecer um novo na rotação seguinte.
Um event de infetados (zombies) fala com um ficheiro de ambiente chamado territory, que define onde pertence esse grupo de infetados. O lado territory é um tema mais profundo, merecedor do seu próprio tutorial, mas as noções básicas chegam para fazer alterações.
Para simplesmente boostar zombies, aumenta as saídas minimum e nominal do event de infetados - raramente precisas de tocar no maximum. Também podes misturar diferentes children de infetados noutros events para os espalhar pelo mapa onde quiseres mais.
Os random presets são o intermediário entre types.xml e os spawnable types. Um preset cria um pool de loot cargo ou attachment com nome: uma lista de types ou classes, cada um com uma hit chance. Quando essa probabilidade calha, é escolhido um dos children do pool.
É assim que obténs variedade dentro ou em cima de um objeto - por exemplo um preset cargo que enche um recipiente, ou um preset attachment que põe um chapéu ou mochila num zombie. O preset só define o pool; é o spawnable type, a seguir, que diz a um item para o usar de facto.
cfgspawnabletypes.xml é o que diz a um type para ter outros types anexados a ele ou dentro dele. É o consumidor dos random presets definidos há pouco: um spawnable type aponta por nome para um preset cargo ou attachment, e as hit chances do preset decidem então o que aparece de facto.
Em resumo, types.xml diz que um item existe, o random preset define um pool de possíveis extras, e o spawnable type liga os dois para que um item recém-aparecido chegue com o cargo e os attachments certos.
globals.xml guarda os interruptores ao nível do servidor, e é mais poderoso do que parece. Lá em baixo está o contador geral de infetados - aumenta-o ou baixa-o para definir a IA máxima permitida. O vanilla anda algalgures entre 1000 e 1200; no build de origem foi baixado para 850. Ao lado encontras o animal count e a rapidez com que um cadáver é limpo.
Um par de valores-chave são as definições idle. Põe ambos os valores idle a zero e a tua economia continua a rodar mesmo sem ninguém online, para que loot e events fiquem frescos num servidor 24/7. Outros interruptores aqui controlam quantas peças de loot aparecem inicialmente, e permitem ligar ou desligar sistemas como wet, world e tents.
Esta é só a visão geral para iniciantes - há mais ficheiros e vídeos bem mais aprofundados sobre cada um. Mas saber como estes ficheiros centrais se referenciam entre si chega para começares a afinar com segurança o loot e os zombies do teu servidor.
Começa em types.xml e aumenta o nominal e o min do item que queres. nominal é a quantidade-alvo que a economia mantém no mundo e min é o limite que dispara novos spawns.
Para um limite geral, aumenta o contador de infetados em globals.xml. Para tornar uma área específica mais movimentada, aumenta o minimum e o nominal do event de infetados relevante em events.xml - normalmente não precisas de tocar no maximum.
Quase sempre uma discrepância de nomes. Um nome de proto tem de corresponder exatamente a um nome de pos, e um nome de event exatamente a um nome de event-spawn. Verifica ortografia e maiúsculas em ambos os lados.
Um random preset (cfgrandompresets.xml) define um pool com nome de possível cargo ou attachments com hit chances. Um spawnable type (cfgspawnabletypes.xml) diz a um item real para usar esse pool - por isso o preset é o intermediário entre types.xml e o que um item carrega ao aparecer.
Em globals.xml põe ambos os valores idle a zero. A economia roda então sem parar, para que um servidor 24/7 fique abastecido com loot e events frescos.