Guia de problemas: "Cannot create", loot fantasma e mods duplicados

Quando você adiciona mods e mexe na economia (types, placement, packs), alguns erros aparecem sempre — e quase todos se diagnosticam lendo o `.RPT` do servidor. Aqui estão os quatro mais comuns, cada um com o caminho completo pra resolver.

1. "Cannot create non-ai vehicle" no .RPT (placement órfão)

16:02:20  Cannot create non-ai vehicle MeuMod_Objeto_01,
16:02:20  Cannot create non-ai vehicle MeuMod_Vending_02,

**Sintoma:** no boot, o `.RPT` enche de `Cannot create non-ai vehicle <classname>`. **Causa:** são objetos de cenário posicionados no `mapgrouppos.xml` (montados no DayZ Editor com o mod carregado), mas o **mod que define aquele classname não está subido** no servidor. O jogo tenta criar o objeto, não acha a classe, e loga o erro.

1. 1Leia o `.RPT` do último boot e liste os classnames em `Cannot create`.
2. 2Procure o classname no `mapgrouppos.xml` (e em spawners/init). Se ele estiver lá e o mod não estiver no `-mod=`, é placement órfão.

**Correção:** ou suba o mod que provê o classname (e mantenha o objeto), ou remova as entradas órfãs do `mapgrouppos.xml` — **sempre com backup antes**. A fonte real das posições é o `.DZE` no `EditorFiles` (só o editor lê; o servidor lê o `mapgrouppos` exportado).

2. Validar se um classname "existe" (types fantasma)

**Sintoma:** dúvida se os `<type>` que você adicionou no `types.xml` (ou num `typesModded.xml`) realmente vão spawnar. **Causa:** um type com classname que não existe no config do mod — digitado errado, ou o mod nem está carregado. O CE aceita o XML, mas o item nunca aparece (loot fantasma).

**Diagnóstico definitivo (CE load test):** suba o servidor uma vez e leia o `.RPT`. `Cannot create` pro seu classname = fantasma; boot limpo = existe. **Sem ferramentas de unpack à mão**, dá pra validar por proxy: cruze os classnames que você adicionou contra os declarados no próprio `types.xml` que o mod entrega — se não está lá, é suspeito.

3. types.xml do mod malformado na origem (multi-root)

**Sintoma:** o parser de XML falha com algo como "o documento já contém o elemento raiz". **Causa:** o autor do mod deixou o arquivo com mais de um nó-raiz ou tags soltas — tecnicamente não é um XML válido.

(?s)<type\b[^>]*>.*?</type>

**Correção:** não tente parsear o arquivo inteiro. **Extraia só os blocos `<type>...</type>` por regex** e valide cada um isoladamente antes de mesclar no seu `types.xml`.

4. PBO duplicado entre mods (pack que embute standalone)

**Sintoma:** servidor inflado, possíveis conflitos, o mesmo conteúdo em dois `@mods`. **Causa:** packs (ex.: um pacote de armas do servidor) embutem mods standalone (o mesmo `.pbo`) que TAMBÉM estão soltos no modlist.

1. 1Liste todos os `.pbo` dos `@mods` e agrupe por nome + tamanho.
2. 2Confirme com hash MD5: hash igual em pastas diferentes = duplicado real.

**Correção:** delete o standalone redundante (o pack já entrega), tire do `-mod=`/`-serverMod=` e remova a `.bikey` correspondente.

Fluxo: completar os types de um mod (passo a passo)

1. 1Ache o `types.xml` do mod (em `files/`, `extra/`, `info/`; se tiver mais de um, use o consolidado).
2. 2Extraia os `<type>` (regex se estiver malformado) e faça dedup contra o seu `types.xml` modado E o `db/types.xml` base — 0 colisão de classname.
3. 3Mescle com um marcador `<!--NOME DO MOD-->` no início e no fim do bloco, mantendo formatação consistente (4 espaços, self-close colado).
4. 4Valide o XML, confira a contagem e faça backup local antes de gravar.
5. 5Suba o servidor uma vez e valide pelo `.RPT` (0 `Cannot create`).
6. 6O `cfgignorelist` recebe os objetos de placement (não-loot); `cfgspawnabletypes`/`cfgrandompresets` só quando você for definir o que spawna.