Ativa o menu
Alternar menu de preferências
Alternar menu pessoal
Não autenticado(a)
Your IP address will be publicly visible if you make any edits.
DoomWiki.org
For more information on this article, visit the PK3 page on the Doom Wiki.
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.
7zuse 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