PK3
Mais ações
- PK3 redireciona para cá. O formato de arquivo PK3 é o mesmo que o formato ZIP e é tratado exatamente da mesma forma pelo ZDoom.
O ZDoom permite usar vários formatos de arquivo compactado em vez dos WADs tradicionais. Principalmente:
ZIP- Um arquivo .zip usado como contêiner para um mod do ZDoom normalmente recebe a extensão .pk3 (originalmente usada pelo Quake 3), .pkz (para ZDoom), .pke (para o Eternity Engine) ou .ipk3 (para jogos completos em ZIP) em vez de .zip. Embora não haja diferença técnica, isso ajuda a evitar confusão de usuários que poderiam pensar que o mod precisa ser extraído e também impede o Windows de apresentá-lo como um diretório. O ZDoom suporta vários métodos de arquivamento ZIP: armazenado (sem compressão), shrunk, imploded,
deflated (o mais comum),
bzip2 e
LZMA. Observe que muitos utilitários ZIP implementam apenas parcialmente o padrão ZIP e, como resultado, suportam apenas arquivos “store” e “DEFLATE”. Essa implementação parcial também afeta algumas ferramentas de edição que normalmente suportam o formato PK3, como (GZ) Doom Builder e SLADE.
7z — use com cautela- Um arquivo .7z usado como contêiner para um mod do ZDoom normalmente recebe a extensão .pk7, .pkz ou .ipk7, por motivos semelhantes. Esse formato oferece uma taxa de compressão muito melhor, mas também aumenta o uso de memória do motor; portanto, é preciso cautela ao escolher entre 7z e ZIP. Uma possibilidade é desenvolver o mod como ZIP e convertê-lo para 7z ao final, para reduzir o tamanho do arquivo distribuído. Porém, tenha em mente que a descompressão é bem mais lenta que a de arquivos ZIP, aumentando os tempos de carregamento, inclusive em tempo de execução (por exemplo, ao carregar novos sons). Aumentar o tempo de carregamento em troca de um arquivo menor geralmente não compensa hoje em dia.
- Pastas
- Pastas podem ser carregadas diretamente pelo ZDoom como se fossem arquivos ZIP ou 7z. Isso é especialmente útil ao criar um mod sem usar um editor como o SLADE, pois permite que o criador faça alterações com suas próprias ferramentas e carregue rapidamente no ZDoom.
Arquivos compactados têm muitas vantagens sobre (P)WADs, mesmo para conteúdo de Doom:
- Tamanho de arquivo menor devido à compressão.
- Uso de memória significativamente reduzido durante o jogo.
- Uso adequado de diretórios em vez de namespaces de WAD.
- Não é mais necessário usar ferramentas dedicadas de gerenciamento de WAD, como XWE.
- Mais flexibilidade graças à possibilidade de usar caminhos completos em vez de nomes de 8 caracteres em muitos sistemas.
Como usar
É possível embutir WADs dentro de arquivos compactados. Qualquer WAD encontrado no diretório raiz também será adicionado ao diretório de lumps. Isso permite carregar muitos ZIPs distribuídos pelo /idgames sem a necessidade de extraí-los. Se vários WADs estiverem incluídos em um arquivo, eles serão carregados em ordem alfabética.
![]() |
Warning: Com exceção de WADs contendo mapas colocados na subpasta /maps/ de um PK3, carregar WADs dentro de um arquivo compactado causará problemas de memória. O ZDoom irá descompactar cada WAD e usar mais memória para acessar o conteúdo. Esse efeito se acumula rapidamente conforme aumenta o número de WADs, podendo fazer o PC do usuário ficar sem memória. Portanto, é altamente recomendável extrair completamente o conteúdo de quaisquer WADs que façam parte do mod para os diretórios organizados.
Além disso, o ZDoom suporta e incentiva o uso de subdiretórios dentro dos principais para fins de organização (por exemplo, sprites/Weapons/Cannon, sprites/Monsters/Technodemon, etc.). Não é necessário nenhum esforço extra para indicar a presença dos sprites, pois o ZDoom escaneia automaticamente todos os subdiretórios. |
Ao contrário dos WADs, que não possuem uma estrutura real de diretórios, a colocação dos dados dentro de arquivos compactados é muito mais estritamente aplicada para que o motor reconheça os dados como lumps padrão. Qualquer dado especial deve ser colocado no diretório correspondente dentro do arquivo ou não será encontrado. Para o nome do lump, os primeiros 8 caracteres do nome do arquivo são usados e a extensão é removida. Por exemplo, para colocar um MAPINFO em um arquivo compactado, você pode nomear o arquivo como MAPINFO.txt, MAPINFO.lmp ou qualquer outra extensão (ou nenhuma) e colocá-lo no diretório raiz do arquivo. Os seguintes subdiretórios são usados para atribuir dados aos namespaces existentes de WAD no ZDoom:
| Diretório | Descrição |
| acs/ | contém bibliotecas ACS normalmente encontradas entre A_START e A_END |
| colormaps/ | contém colormaps Boom normalmente encontrados entre C_START e C_END. Novos WADs para ZDoom geralmente não precisam usar isso. |
| filter/ | contém lumps e diretórios que só serão carregados com jogos específicos. Veja filtro de lumps. |
| flats/ | contém flats normalmente encontrados entre FF_START e FF_END |
| graphics/ | Todos os gráficos especiais, como telas de título ou caracteres de fonte, devem ficar aqui. Esse namespace não existe em WADs. |
| hires/ | contém texturas de alta resolução normalmente encontradas entre HI_START e HI_END |
| maps/ | contém níveis na forma de WADs. Esses WADs devem conter dados de apenas um único nível (incluindo GL nodes, se necessário). Qualquer outro dado nesses WADs será ignorado. Note que o nome do arquivo, e não o rótulo interno do mapa, determina o nome do mapa no jogo. |
| music/ | contém todos os dados usados como música. Esse namespace não existe em WADs. |
| patches/ | contém patches normalmente encontrados entre PP_START e PP_END |
| sounds/ | contém todos os arquivos de som referenciados por SNDINFO. Esse namespace não existe em WADs. |
| sprites/ | contém sprites normalmente encontrados entre S_START e S_END (também conhecidos como SS_START e SS_END) |
| textures/ | contém textures normalmente encontradas entre TX_START e TX_END (namespace de substituição de texturas) |
| voices/ | contém sons de diálogo de Strife normalmente encontrados entre V_START e V_END |
| voxels/ | contém objetos voxel normalmente encontrados entre VX_START e VX_END |
| / | contém objetos no namespace global, como MAPINFO e arquivos ZScript |
Dicas
- SLADE ou programas semelhantes são recomendados para criar o arquivo compactado, garantindo que ferramentas como WinZIP ou WinRAR não o criem com compressão não suportada. Caso contrário, o arquivo pode parecer corrompido, dificultando edições no SLADE, Slumped etc.
- O SLADE também é capaz de editar muitos tipos de arquivo com realce de sintaxe, semelhante a um ambiente de desenvolvimento integrado, sendo muito útil para escrever DECORATE e similares.
- O diretório do arquivo compactado é ordenado alfabeticamente antes de ser adicionado ao diretório de lumps; quaisquer WADs na raiz são carregados depois. Leve isso em conta ao criar dados que dependam da ordem dos nomes de arquivos. Na maioria dos casos não é necessário depender de ordenação, com exceção de animações de textura do tipo range que animam texturas dos subdiretórios flats/ ou textures/.
- Qualquer arquivo que não esteja em um dos diretórios reservados não é adicionado ao diretório de WAD e só pode ser usado por código que procure caminhos completos.
- Lumps de sprite para o frame \ em um WAD (como VILE\* para um dos frames de cura do Arch-Vile) podem ser colocados em um arquivo compactado; o caractere barra invertida deve ser substituído por um circunflexo (^). Assim, VILE^1 a VILE^8 serão interpretados como VILE\1 a VILE\8. Essa substituição funciona apenas para sprites.
- É fortemente recomendado usar as extensões .pk3, .pk7 ou .pkz, e não .zip ou .7z, ao criar um arquivo destinado a ser carregado diretamente no ZDoom.
- O conteúdo dos arquivos dentro do arquivo compactado deve ser idêntico aos lumps de um WAD. Isso é especialmente importante para gráficos. O ZDoom não lê arquivos .BMP! Para que gráficos sejam reconhecidos, eles devem estar no formato interno do Doom ou em um formato de imagem suportado, como PNG.
- Cuidado com arquivos ocultos! Ao adicionar diretórios inteiros, arquivos de sistema indesejados (como thumbs.db do Windows) podem ser incluídos, aumentando o tamanho e gerando avisos. O Slumped frequentemente trava ao encontrar esses arquivos.
Usando pastas em vez de arquivos
![]() |
Warning: Embora trabalhar a partir de pastas seja muito conveniente durante o desenvolvimento, e elas possam ser abertas no SLADE, saiba que o SLADE não cria backups para pastas, ao contrário de WADs e PK3s. Você deve cuidar dos backups manualmente. O método mais conveniente é transformar a pasta do projeto em um repositório Git. |
Um mod PK3/ZIP não precisa estar empacotado para funcionar. Se estiver descompactado em uma pasta com a mesma estrutura interna de um PK3, funcionará da mesma forma. O GZDoom pode executar pastas como se fossem arquivos PK3, por exemplo:
gzdoom.exe -iwad doom2.wad -file mods\mymod
“Mymod” neste exemplo é o nome de uma pasta que contém os mesmos lumps e subpastas, como Sprites, Textures, etc. Lumps podem usar qualquer extensão ou nenhuma; por exemplo, MAPINFO.txt, MAPINFO.mod ou apenas MAPINFO funcionam.
Caminhos longos também são suportados:
gzdoom.exe -iwad tnt.wad -file "C:\Doom\My Projects\MyWipMod"
O SLADE também pode abrir pastas e analisá-las como WAD ou PK3 usando File > Open Directory.
Há várias vantagens significativas em usar pastas em vez de PK3, sendo geralmente uma ótima ideia manter mods em desenvolvimento em uma pasta e empacotá-los apenas ao final:
- Você não precisa usar o SLADE para editar tudo; pode usar seu software favorito (por exemplo, editar ZScript/DECORATE em editores de código).
- Não é necessário abrir o arquivo inteiro para editar apenas uma parte específica.
- O SLADE é propenso a travamentos ocasionais e corrupção de dados; usar pastas reduz esse risco.
- O SLADE ainda é necessário para tarefas como ajuste de offsets de sprites, mas você pode abrir apenas subdiretórios específicos.
- Você pode transformar a pasta em um repositório GitHub, facilitando controle de versão e colaboração.
Notas:
- Editores externos não têm dicas pop-up integradas para funções ZScript/DECORATE.
- O GZDoom pode demorar um pouco mais para carregar uma pasta do que um PK3.
- Muitos editores visuais removem metadados de offset; após editar sprites, use o SLADE para redefini-los (ou defina offsets no TEXTURES).
- O SLADE não cria backups para pastas; com GitHub isso deixa de ser um problema.
Armazenando mapas em um PK3
Os mapas só podem existir dentro de arquivos WAD; todos os outros recursos e código devem ficar em um PK3. Para empacotar tudo em um único PK3: 1. Cada mapa deve ser salvo em um WAD separado, com nome correspondente ao nome interno definido em MAPINFO (ex.: MAP01.wad, E1M1.wad). 2. Todos os WADs de mapas devem ficar em maps/ dentro do PK3. 3. O lump MAPINFO deve ficar na raiz do PK3 (junto de ZScript, MODELDEF, ANIMDEFS etc.).
Evite colocar mapas na raiz do PK3: isso fará o GZDoom carregar todos os mapas na memória de uma vez, prejudicando o desempenho.
Compatibilidade
Ferramentas modernas lidam bem com pastas e ZIPs, mas nenhuma suporta 7z atualmente.
Vavoom e Doomsday também usam ZIPs, porém com organização diferente de subdiretórios. Adaptar mods pode exigir reempacotamento e conversões. O Eternity Engine adotou um modelo semelhante ao do ZDoom, mas com diferenças suficientes para causar incompatibilidades.
Veja também
Página original (em inglês): https://zdoom.org/wiki/PK3

