Как создать файл pk3

Обновлено: 07.07.2024

ZDoom позволяет использовать несколько форматов сжатия вместо обычных WAD-файлов. В частности:

ZIP
ZIP-файлу, использующемуся в качестве контейнера для мода, обычно даётся расширение .pk3 вместо .zip. Хотя технически они не отличаются, это помогает избежать потенциальной путаницы у пользователей, которые могут подумать, что мод нужно извлекать из архива, а также предотвращает распознавание этого файла Windows и последующее его отображение в виде папки. ZDoom поддерживает несколько алгоритмов сжатия: без сжатия, "shrinking", "imploding", "deflate" (наиболее часто используемый), bzip2 и LZMA. Стоит отметить, что многие ZIP-утилиты лишь частично реализуют стандарт ZIP, поэтому ограничиваются поддержкой архивации без сжатия и "deflate". Такая частичная реализация также наблюдается в некоторых редакторах, поддерживающих формат PK3, таких как Doom Builder 2 и Slumped.

7z
7z-файлу, использующемуся в качестве контейнера для мода, обычно даётся расширение .pk7 по тем же причинам. Этот формат предлагает более высокую степень сжатия, однако имеет ограниченную поддержку, особенно в утилитах для моддинга, что делает его менее интересным. Также его использование увеличивает объём памяти, занимаемой движком, поэтому нужно выбирать осторожно между форматами 7z и PK3. Можно сделать мод в PK3, задем преобразовать его в PK7, когда он закончен, чтобы уменьшить размер распространяемого файла. Однако стоит помнить, что распаковывается он медленнее, чем zip, поэтому и загружается дольше.

Сжатые архивы имеют много преимуществ перед PWAD-ами, даже если используются для хранения контента для Doom:
-Меньший размер файла из-за сжатия
-Намного уменьшенное использование памяти во время игры
-Должное использование структуры папок вместо разделителей в WAD-ах.
-Больше не нужно использовать отдельные инструменты редактирования WAD вроде XWE для управления данными.
-Большая гибкость благодаря использованию полных путей к файлам. На данный момент поддержка ограничена, но планируется добавить поддержку полных путей везде, где есть ссылки на имена lump-ов.

Как
Можно вставить WAD-ы внутрь ZIP. Любой WAD-файл, найденный в корневой директории, будет добавлен в директорию lump-ов. Это позволяет загружать многие ZIP-файлы, распространяемые через /idgames без необходимости извлечения. Если в архиве содержится несколько файлов, они будут загружаться в алфавитном порядке.

Так вот, позавчера какого-то чувака (кажись, как раз автора темы) забанили на автоматизированных хостингах Зандра (BE) за попытку упаковать несколько чужих вадов в .pk3 и поставить на сервер одним файлом
Это не ты был, нет? Чисто так из интереса вопрос.

А вообще, если у тебя например карта в формате UDMF, то всё же есть смысл упаковать единственный вад в .pk3, и сам .pk3 упаковать в .zip вместе с .txt.
Потому что минимальная полноценная карта в UDMF весит мегабайт. +

Добавлено спустя 1 минуту 25 секунд:

ZDoom позволяет использовать несколько форматов сжатия вместо обычных WAD-файлов. В частности:

7z
7z-файлу, использующемуся в качестве контейнера для мода, обычно даётся расширение .pk7 по тем же причинам. Этот формат предлагает более высокую степень сжатия, однако имеет ограниченную поддержку, особенно в утилитах для моддинга, что делает его менее интересным. Также его использование увеличивает объём памяти, занимаемой движком, поэтому нужно выбирать осторожно между форматами 7z и PK3. Можно делать мод в PK3, затем преобразовать его в PK7, когда он закончен, чтобы уменьшить размер распространяемого файла. Однако стоит помнить, что распаковывается он медленнее, чем zip, поэтому и загружается дольше.

Сжатые архивы имеют много преимуществ перед PWAD'ами, даже если используются для хранения контента для Doom:
-Меньший размер файла из-за сжатия
-Намного уменьшенное использование памяти во время игры
-Должное использование директорий вместо разделителей в WAD'ах.
-Больше не нужно использовать отдельные инструменты редактирования WAD вроде XWE для управления данными.
-Большая гибкость благодаря использованию полных путей к файлам. На данный момент поддержка ограничена, но планируется добавить поддержку полных путей везде, где есть ссылки на имена lump-ов.

Как
Можно вставить WAD'ы внутрь ZIP. Любой WAD-файл, найденный в корневой директории, будет добавлен в директорию lump'ов. Это позволяет загружать многие ZIP-файлы, распространяемые через /idgames, без необходимости извлечения. Если в архиве содержится несколько файлов, они будут загружаться в алфавитном порядке.

В отличие от WAD'ов, у которых нет настоящей структуры директорий, размещение данных внутри ZIP'ов соблюдается более строго для того, чтобы позволить движку распознать их как lump по умолчанию. Данные одного типа нужно поместить в соответствующую папку внутри ZIP, иначе они не будут найдены. Для имени lump используются первые 8 символов имени файла, расширение убирается. Например для того, чтобы поместить MAPINFO в ZIP-файл, нужно назвать ваш файл MAPINFO.TXT, MAPINFO.LMP (или любое расширение, какое хотите) и поместить его в корневую директорию ZIP-архива. Для распределения данных по существующим пространствам имён в ZDoom используются следующие подпапки:

Директория Описание
patches/ содержит patch'и, обычно находящиеся между PP_START и PP_END
graphics/ все особые графические файлы, такие как заглавные изображения или символы шрифта, должны быть здесь. Этого пространства имён не существует в WAD'ах.
sounds/ содержит все звуковые файлы, на которые ссылается SNDINFO. Этого пространства имён не существует в WAD'ах.
music/ содержит все данные, используемые в качестве музыки. Этого пространства имён не существует в WAD'ах.
maps/ содержит уровни в форме WAD'ов. Каждый из этих WAD'ов должен содержать данные для одного уровня (включая lump'ы GL nodes, если требуется). Любые другие данные в таких WAD'ах игнорируются. Следует заметить, что имя файла, а не номер карты внутри WAD'а, определяет имя карты в игре.
flats/ содержит flat'ы, обычно находящиеся между FF_START и FF_END
sprites/ содержит спрайты, обычно находящиеся между S_START и S_END (а также SS_START , SS_END )
textures/ содержит текстуры, обычно находящиеся между TX_START и TX_END
hires/ содержит текстуры высокого разрешения, обычно находящиеся между HI_START и HI_END
colormaps/ содержит Boom'овские цветовые карты, обычно находящиеся между C_START и C_END . Новые ZDoom-WAD'ы не должны это использовать
acs/ содержит библиотеки ACS, обычно находящиеся между A_START и A_END
voices/ содержит звуки диалогов Strife, обычно находящиеся между V_START и V_END
voxels/ содержит воксельные объекты, обычно находящиеся между VX_START и VX_END

(Примечание: любой lump, найденный в корневой директории, добавляется в глобальное пространство имён)

Совместимость
На данный момент единственные редакторы, поддерживающие этот формат - это Doom Builder 2, SLumpEd, Slade 3, но вы, конечно, можете использовать любой доступный Zip-инструмент, если вам не нужен доступ к особым возможностям Doom, таким как определения текстур и смещение графики.
Vavoom и Doomsday также используют PK3-файлы для своих ресурсов; однако организация подпапок у них отличается. Адаптация мода, предназначенного для этих портов, к ZDoom, может потребовать перепаковки, в дополнение к преобразованию возможностей портов в их ZDoom-аналог. Eternity Engine использует модель, похожую на ZDoom, но имеющую отличия, достаточные для несовместимости.

Такая муля. Решил я упростить счёт итемов, написал 2 wav файла где с за 10 и за 5 секунд сообщал о появлении меги и красного.. открыл винраром архив PAK0.pk3, сунул их туда и снова запаковал. Пробиндил в конфиге команды play и стал радоваться жизни когда всё поканало. Но! Оказалось что с этого момента ко мне не могут приконнектиться друзья квакеры (у меня локальная сеть..) пока я не скину им свой PAK0.pk3.. Плюс к тому же я отныне не могу приконнектиться к серверу в нете (проблемы с CD KEY) Напрашивается вывод, что таким кустарным методом низя карёжить pk3 файлы. Подскажите как это можно делать и можно ли вообще?
Q3 FOREVER. %)))

по идее надо было просто создать папку sound в baseq3 и запихнуть туда это два файла. пак-файлы НЕ рекомендуется изменять

ты знаешь такую комманду, которая б проигрывала звуки мз папкиBASEQ3? Я знаю только команду Play, которая играет звуки из рак0 и тока из пак0.

Да и пак0 я фактически не изменял, а просто в его корень сунул 2 файла.
Кароче х.з.!

всё, я понял как сделать:

1. копируешь какой-нить маленький уже сущ-ий пак-файл (в папке baseq3).
2. открываешь его winrar'ом.
3. стираешь всё содержимое.
4. создаёшь папку sound на desktop'е, в неё пихаешь свой звуковой файл.
5. перетаскиваешь эту папку в пустой пак-файл.
6. закрываешь winrar и переименовываешь новый пак, к примеру, на pak950.pk3
7. в конфиге прописываешь (это пример):
bind k "play sound/mywav1"
bind l "play sound/mywav2" и т.д.

GTA: The Trilogy — The Definitive Edition работает на движке Unreal Engine, и для хранения игровых файлов в этом движке используются паки (файлы с расширением .pak). Чтобы установить мод для обновленной трилогии, необходимо создать свой .pak файл, в который положить измененные файлы. Но как это сделать?

В данной статье вы узнаете, как распаковать game.pak, в котором лежат все игровые файлы, а также мы расскажем о создании своих .pak файлов.

Как распаковать игровые файлы GTA: The Trilogy — The Definitive Edition

Скачайте программу Umodel. Запустите umodel_gta_trilogy.exe.

Перед вами откроется структура пака. Щелкните на кнопку «Инструменты» (Tools) и перейдите в «Параметры» (Options).

Здесь вы можете настроить параметры извлечения и сохранения извлеченных файлов. Рекомендуем установить параметры, как на скриншоте ниже, это упростит вам работу в будущем. Щелкните ОК.

Чтобы что-то извлечь, просто выберите файл в списке и нажмите «Экспорт» (Export). Вам будет предложено указать версию Unreal Engine, выберите 4.26 и нажмите OK. В приведенном ниже примере мы экспортировали файл SM_colt45.uasset, расположенный в Game SanAndreas Weapons. Этот формат можно открыть в Blender и экспортировать в .OBJ.

Как создать свой pak файл для GTA: The Trilogy — The Definitive Edition

Вы отредактировали какой-то игровой файл и теперь хотите добавить его в игру. Для этого нужно создать свой pak файл, но как это сделать?

Вам потребуется программа UnrealPak, которую можно скачать с GitHub . После установки программы запустите командную строку и пропишите следующий код:

"D:GamesEpic GamesUE_4.25EngineBinariesWin64UnrealPak.exe" “D:UnpacksExtractedDataTest.pak” -Create= "D:UnpacksExtractedDatadataToPack.txt"

Test.pak - пак, который будет сгенерирован, dataToPack.txt - файл, который будет в него упакован. Путь к UnrealPak.exe и путь, где будет создан новый pak файл вы должны указать сами.

Обратите внимание, что внутри вашего пака структура файлов должна совпадать с той, что находится в оригинальном game.pak. в ином случае мод работать не будет! Посмотреть структуру вы можете в распакованном game.pak

Советы по поиску игровых файлов

Текстуры из gta3img обычно находятся в SanAndreas Textures gta3 (они разделены по категориям);
В верхней части программы есть кнопка с изображением лупы - она ищет файлы только в той папке, в которой вы находитесь (не включает вложенные папки).

Наша команда Immunant любит Rust и активно работает над C2Rust — фреймворком миграции, берущим на себя всю рутину миграции на Rust. Мы стремимся автоматически вносить в преобразованный код на Rust улучшения безопасности и помогать программисту делать это самому, когда не справляется фреймворк. Однако в первую очередь нам нужно создать надёжный транслятор, позволяющий пользователям приступить к работе с Rust. Тестирование на мелких CLI-программах потихоньку устаревает, поэтому мы решили перенести на Rust игру Quake 3. Спустя пару дней мы, скорее всего, стали первыми, кому удалось сыграть в Quake3 на Rust!

Подготовка: исходники Quake 3

Изучив исходный код оригинального Quake 3 и различных форков, мы остановились на ioquake3. Это созданный сообществом форк Quake 3, который до сих пор поддерживается и собирается на современных платформах.

В качестве отправной точки мы решили убедиться, что сможем собрать проект в его исходном виде:

При сборке ioquake3 создаётся несколько библиотек и исполняемых файлов:

Среди этих библиотек, библиотеки UI, клиента и сервера можно собрать или как сборку Quake VM, или как нативные библиотеки общего пользования X86. В своём проекте мы решили использовать нативные версии. Транслирование VM на Rust и использование QVM-версий были бы значительно проще, но мы хотели тщательно протестировать C2Rust.

В своём проекте переноса мы сосредоточились на UI, игре, клиенте, OpenGL1-рендерере и основном исполняемом файле. Можно было бы транслировать и OpenGL2-рендерер, но мы решили пропустить это, потому что в нём используется значительный объём файлов шейдеров .glsl , которые система сборки встраивает как строковые литералы в исходном коде на C. После выполнения транспиляции мы добавим поддержку скриптов сборки для встраивания кода GLSL в строки Rust, но пока нет хорошего автоматизированного способа транспиляции этих автоматически сгенерированных временных файлов. Поэтому вместо этого мы просто транслировали библиотеку OpenGL1-рендерера и принудительно заставили игру использовать его вместо рендерера по умолчанию. Кроме того, мы решили пропустить выделенный сервер и упакованные файлы миссий, потому что их несложно будет перенести и они необязательны для нашей демонстрации.

Транспилируем Quake 3

Чтобы сохранить структуру каталогов, используемую в Quake 3, и не изменять исходный код, нам нужно было получить точно такие же двоичные файлы, как и в нативной сборке, то есть четыре библиотеки общего пользования и один исполняемый файл.

Так как C2Rust создаёт файлы сборки Cargo, каждый двоичный файл требует собственного Rust crate с соответствующим файлом Cargo.toml .

Чтобы C2Rust создавал по одному crate на каждый выходной двоичный файл, ему также понадобится список двоичных файлов с соответствующим объектом или исходными файлами, а также вызов компоновщика, используемый для создания каждого двоичного файла (применяется для определения других подробностей, например, библиотечных зависимостей).

Однако мы быстро столкнулись с одним ограничением, вызванным тем, как C2Rust перехватывает нативный процесс сборки: C2Rust получает на входе файл базы данных компиляции, который содержит список команд компиляции, выполняемых во время сборки. Однако эта база данных содержит только команды компиляции без вызовов компоновщика. Большинство инструментов, создающих эту базу данных, имеют это намеренное ограничение, например, cmake с CMAKE_EXPORT_COMPILE_COMMANDS , bear и compiledb . По нашему опыту, единственным инструментом, включающим команды компоновки, является build-logger , созданный CodeChecker , который мы не использовали, потому что узнали о нём только после написания собственных обёрток (о них рассказывается ниже). Это означало, что для транспиляции программы на C с несколькими двоичными файлами мы не могли использовать файл compile_commands.json , созданный любым из распространённых инструментов.

Поэтому мы написали собственные скрипты обёрток компилятора и компоновщика, которые дампят все вызовы компилятора и компоновщика в базу данных, а затем преобразуют его в расширенный compile_commands.json . Вместо обычной сборки, использующей команду наподобие:

мы добавили обёртки для перехвата сборки при помощи:

Обёртки создают каталог из нескольких файлов JSON, по одному на вызов. Второй скрипт собирает всех их в один новый файл compile_commands.json , который содержит команды и компиляции, и компоновки. Затем мы расширили C2Rust, чтобы он считывал команды компоновки из базы данных и создавал отдельный crate на каждый скомпонованный двоичный файл. Кроме того, C2Rust теперь ещё и считывает библиотечные зависимости для каждого двоичного файла и автоматически добавляет их в файл build.rs соответствующего crate.

Для повышения удобства все двоичные файлы можно собрать за раз, расположив их внутри workspace. C2Rust создаёт файл workspace Cargo.toml верхнего уровня, поэтому мы можем собрать проект единственной командой cargo build в каталоге quake3-rs :

Устраняем шероховатости

Когда мы впервые попробовали собрать транслированный код, то столкнулись с парой проблем с исходниками Quake 3: возникли граничные случаи, которые C2Rust не мог обработать (ни корректно, ни вообще хоть как-нибудь).

Указатели на массивы

В нескольких местах оригинального исходного кода содержатся выражения, указывающие на следующий после последнего элемент массива. Вот упрощённый пример кода на C:

Стандарт C (см., например, C11, Section 6.5.6) позволяет указателям на элемент выходить за конец массива. Однако Rust запрещает это, даже если мы только берём адрес элемента. Мы нашли примеры такого паттерна в функции AAS_TraceClientBBox .

Компилятор Rust также сигнализировал о подобном, но на самом деле содержащем ошибку примере в G_TryPushingEntity , где условная инструкция имеет вид > , а не >= . Вышедший за границы указатель затем разыменуется после условной конструкции, что является багом безопасности памяти.

Чтобы избежать этой проблемы в будущем, мы исправили транспилятор C2Rust так, чтобы он использовал арифметику указателей для вычисления адреса элемента массива, а не применял операцию индексирования массива. Благодаря этому исправлению код, использующий подобный паттерн «адрес элемента за концом массива», теперь корректно транслируется и выполняется без модификаций.

Элементы массивов переменной длины

Мы запустили игру, чтобы всё протестировать, и сразу же получили panic от Rust:

Взглянув на cm_polylib.c , мы заметили, что он разыменовывает поле p в следующей структуре:

Поле p в структуре — это неподдерживаемая до стандарта C99 версия элемента массива переменной длины (flexible array member), который тем не менее принимается gcc . C2Rust распознаёт элементы массивов переменной длины с синтаксисом C99 ( vec3_t p[] ) и реализует простую эвристику, чтобы также определить версии этого паттерна до C99 (массивы размером 0 и 1 в конце структур; также мы нашли несколько таких примеров в исходном коде ioquake3).

Изменение представленной выше структуры на синтаксис C99 устранило panic:

Попытка автоматического исправления этого паттерна в общем случае (при размерах массивов, отличающихся от 0 и 1) будет чрезвычайно сложной, потому что нам придётся различать обычные массивы и элементы массивов переменной длины произвольных размеров. Поэтому вместо этого мы рекомендуем исправлять оригинальный код на C вручную, как мы и сделали с ioquake3.

Tied Operands во встроенном ассемблерном коде

Ещё одним источником сбоев был этот встроенный в C ассемблерный код из системного заголовка /usr/include/bits/select.h :

определяющий внутреннюю версию макроса __FD_ZERO . Это определение вызывает редкий граничный случай встроенного ассемблерного кода gcc : tied operands ввода-вывода с разными размерами. Оператор вывода "=D" (__d1) привязывает регистр edi к переменной __d1 как 32-битное значение, а "1" (&__FDS_BITS (fdsp)[0]) привязывает тот же регистр к адресу fdsp->fds_bits как 64-битный указатель. gcc и clang устраняют это несовпадение. используя 64-битный регистр rdi и усекая его значение перед присвоением значения __d1 , а Rust по умолчанию использует семантику LLVM, в которой такой случай остаётся неопределённым. В отладочных сборках (не в релизных, которые вели себя хорошо) мы увидели, что оба операнда можно присвоить регистру edi , из-за чего указатель усекается до 32 бит перед встроенным ассемблерным кодом, что вызывает сбои.

Стоит заметить, что этот код не требует никаких типов для входных и выходных значений в конструкции ассемблерного кода, при разрешении конфликтов типов полагаясь вместо них на вывод типов Rust (в основном типов fresh6 и fresh8 ).

Выровненные глобальные переменные

Последним источником сбоев была следующая глобальная переменная, хранящая константу SSE:

В настоящее время Rust поддерживает атрибут выравнивания для структурных типов, но не для глобальных переменных, т.е. элементов static . Мы рассматривали способы решения этой проблемы в общем случае или в Rust, или в C2Rust, но в ioquake3 пока решили устранить её вручную коротким файлом patch. Этот файл patch заменяет эквивалент Rust ssemask следующим:

Запуск quake3-rs

При запуске cargo build --release создаются двоичные файлы, но они создаются под target/release со структурой каталогов, который двоичный файл ioquake3 не распознаёт. Мы написали скрипт, создающий символьные ссылки в текущем каталоге для воссоздания правильной структуры каталогов (в том числе ссылки на файлы .pk3 , содержащие ресурсы игры):

Путь /path/to/paks должен указывать на каталог, содержащий файлы .pk3 .

Теперь давайте запустим игру! Нам нужно передать +set vm_game 0 и т.п., поэтому мы загружаем эти модули как библиотеки общего пользования Rust, а не как сборку QVM, а также cl_renderer для использования OpenGL1-рендерера.

Мы запустили Quake3 на Rust!

Вот видео того, как мы транспилируем Quake 3, загружаем игру и немного в неё играем:

Можете изучить транспилированные исходники в ветке transpiled нашего репозитория. Также там есть ветка refactored , содержащая те же исходники с несколькими предварительно применёнными командами рефакторинга.

Как выполнить транспиляцию

Если вы хотите попробовать транспилировать Quake 3 и запустить его самостоятельно, то учтите, что вам потребуются собственные игровые ресурсы Quake 3 или ресурсы демо из Интернета. Также нужно будет установить C2Rust (на момент написания требуемая nightly-версия — это nightly-2019-12-05 , но мы рекомендуем заглянуть в репозиторий C2Rust или в crates.io, чтобы найти самую новую версию):

и копии наших репозиториев C2Rust и ioquake3:

В качестве альтернативы установке c2rust с помощью приведённой выше команды можно собрать C2Rust вручную при помощи cargo build --release . В любом случае репозиторий C2Rust всё равно понадобится, потому что он содержит скрипты обёрток компилятора, требуемые для транспиляции ioquake3.

Мы выложили скрипт, автоматически транспилирующий код на C и применяющий патч ssemask . Чтобы воспользоваться им, запустите следующую команду из верхнего уровня репозитория ioq3 :

Эта команда должна создать подкаталог quake3-rs , содержащий код на Rust, для которого можно затем выполнить команду cargo build --release и оставшиеся шаги, описанные выше.

Читайте также: