Эта тема поможет Вам влиться в мир моддинга последней вышедшей игры серии S.T.A.L.K.E.R. – Call of Pripyat, или же по-русски: Зов Припяти. Перед созданием своего мода Вам стоит определиться, что Вы хотите получить в итоге: текстурный, сюжетный, геймплейный или же глобальный мод. Определите его идею, концепцию. Запишите задачи, если работаете в команде, то разделите их на всех, чтобы никто не делал одну и туже задачу. Строгой очередности при создании мода – нету, и быть не может, потому что все зависит только от Вас. Не изобретайте велосипеды, посмотрите на другие моды и достаньте «велосипед» оттуда, только не забывайте указывать авторов мода, откуда была взята наработка. Но и не стоит просто копировать «велосипед», проверьте его на лишние, неправильные запчасти. Велосипед будет ездить с тремя педалями и погнутым колесом, но нужна ли нам третья педаль, и хорошо ли ездить с погнутым колесом? Однозначно нет, поэтому проверяйте. По выпуску мода не спешите его выкладывать в сеть, организуйте своему моду ЗБТ (Закрытое Бета Тестирование) или ОБТ (Открытое Бета Тестирование). Не стоит полагаться на то, что Вы прошли мод и багов нету, потому что у всех игроков своя манера прохождения игры, и то, что Вы никогда бы не сделали, может постоянно делать Вася Пупкин из Зеленогорска. И Вася потеряет интерес к моду, если он будет вылетать каждый час. Поэтому устраивайте тестирование своим продуктам.
Все игровые ресурсы хранятся в db-архивах, и для начала их нужно распаковать. Для их распаковки можно использовать программу S.T.A.L.K.E.R. Universal Extractor (SUE) от товарища Dordex. Использовать ее просто: Запускаете программу, выбираете игру (у нас это Зов Припяти) и выбираете корневую папку. После этого программа все распакует в папку gamedataUE (папка будет лежать в корневой директории игры). Так как эта папка игрой никак не воспринимается, мы будем брать из нее необходимые файлы и ложить их по тому-же пути, но в папку gamedata.
Ai – Содержит файлы отвечающие за коэффициенты вероятностей игровых событий, но это не факт. Не редактируются, за неимением средств для редактирования. Anims – Содержит файлы пост эффектов, анимаций камеры и некоторых объектов. Содержат 2 вида файлов: *.ppe – Файлы пост эффектов, редактируются утилитой PostProcess Editor из состава X-Ray SDK COP; *.anm – Файлы анимаций камеры и объектов, компилируются и декомпилируются утилитой anm2ltx. Также создаются программой Level Editor из состава X-Ray SDK COP Configs – Содержит файлы с параметрами практически всех объектов в игре. Содержат 2 вида файлов: *.xml – Файлы со стандартным XML синтаксисом, можно редактировать любым текстовым (но не офисным) редактором, но лучше для этих целей подобрать редактор с подсветкой синтаксиса, например: Sublime Text 2, Notepad++; Также, для проверки может послужить и браузер Opera: Если он найдет ошибку, он вежливо укажет нам на нее. *.ltx – Файлы с MS-INI синтаксисом, подойдут программы представленные выше. Levels – Содержит папки игровых локаций. Редактируются посредством компилятора\декомпилятора X-Ray Game Asset Tool Converter и X-Ray SDK COP Meshes – Содержит 3D-модели игры в формате *.ogf. Посмотреть их можно в программе OGFViewer. Редактировать их можно в 3D-редакторах со специальными плагинами импорта\экспорта. Такие плагины есть для Maya (7.0, 8.0, 8.5, 2008, 2009, 2010, 2011, 2012), 3DS Max (8.0, 9.0, 2008, 2009, 2010, 2011, 2012), Milkshape и LightWave 8.0 Scripts – Содержит скриптовые файлы игры, написанные на языке LUA. Для редактирования сгодятся выше представленные утилиты - Sublime Text 2, Notepad++. Shaders – Содержит файлы шейдеров для рендеров (r1 - статическое освещение, r2 - динамическое, r3 - улучшенное динамическое). Редактируются утилитой ShaderEditor из состава X-Ray SDK COP Sounds – Содержит все звуковые файлы игры в формате *.ogg. Этот формат поддерживают множество конвертеров, но обычной конвертации не хватает. Файлы необходимо еще прокомментировать в ActorEditor из состава X-Ray SDK COP, делается это для того чтобы игра (точнее ее объекты) правильно обрабатывали эти звуки. Spawns – Содержит один единственный файл, сердце всей игры - all.spawn. В этом файле хранятся данные о местоположении всех динамических (не "приклеенных" к карте) объектов в игре, за исключением скриптовых. Этот файл считывается всего один раз - при новой игре, поэтому после малейшего его изменения нужно начинать новую игру, за исключением правок вейпоинтов (точек путей). Декомпилировать и компилировать его может только одна утилита – ACDC. Textures – Содержит текстуры и видеоролики игры, а также файлы *.seq, которые используются при создании анимаций *.dds – Текстуры. Смотреть можно через XnView и Windows Texture View (WTV), а редактировать можно в Adobe Photoshop, Paint.NET, GIMP - но для всех необходимо скачивать дополнительный плагин для работы с форматом DDS (подробнее о формате DDS) *.thm – Файл параметров текстур. Создается в ActorEditor из состава X-Ray SDK COP *.seq – Файл для создания последовательности кадров из текстур. Редактируется любым текстовым редактором. *.ogm – Видеофайл формата *.ogv (OGG Theora Video), можно переконвертировать с помощью Xilisoft Video Converter Ultimate
Эти 0 пользователя(ей) поблагодарили STANDBUY за это полезное сообщение:
Файл состоит из секций, их параметров и комментариев. Секция – это блок свойств одного объекта, которыми будет манипулировать игра Параметр – это переменная характеризующая то или иное свойство объекта. Комментарий – это строка, помогающая улучшить читабельность кода, в игре она никоим образом не учитывается. Комментарии идут за знаком “;” до конца строки. Помимо этих трех терминов существует еще 2 операции: #include "file_path" - Отвечает за включение дополнительного файла для обработки, его использование рассмотрим чуть ниже Наследование родительских секций (об использовании чуть ниже) – Чтобы не писать кучу параметров, можно их унаследовать от ранее заявленной секции и чем больше они схожи, тем меньше придется заполнять новую секцию. Мы рассмотрели термины и операции, но не увидели как они выглядят вживую, давайте это исправим.
Quote
#include "addition/file.ltx" ; Первая секция [section_parent] $class = WP_LR300
[section_first] $class = WP_SVD ; Класс объекта cost = 2000 ; Номинальная цена name = section_first_name ; Ссылка на имя отображаемое в игре (ссылка ведет на файлы локализаций)
[section_second]:section_parent cost = 2500 descr = section_second_descr ; Ссылка на описание отображаемое в игре
[section_third]:section_first,section_second name = section_third_name
В вышепредставленном листинге можно увидеть добавление доп. файла (1 строка), 4 секции (section_first, section_second, section_third, section_parent), параметры с их значениями ($class, cost, name, descr), использование родительских секций (section_first и section_second для section_third, section_parent для section_second). Из вышеперечисленного следует объяснить пожалуй использование нескольких родительских секций у section_third: Первоначальные значения секция наследует от section_first (т.е. мы получаем переменные: $class = WP_SVD, cost = 2000, name = section_first_name), но затем наследует параметры section_second, который в свою очередь наследует параметры от section_parent (мы получаем параметры: $class = WP_LR300, cost = 2500, descr = section_second_descr). Теперь наложим друг на друга эти параметры (не забываем параметры из самой section_third), я представлю это Вам в виде таблицы:
Как можно заметить из таблицы, использование первой родительской секции (section_first) не оправдано, ибо все параметры были изменены в ходе операций.
Файл XML визуально можно представить как дерево. В XML файле должны обязательно присутствовать: Строка объявления кодировки текста. Для “Зов Припяти” эта строка выглядит так:<?xml version='1.0' encoding="windows-1251"?> Корневой элемент – это главная “нода”, единственная на весь файл (и на все включенные в него файлы), в которую “вкладываются” остальные ноды Выше мы затронули слово “нода”, давайте объясню что это: Нода – (от англ. node - узел) это совокупность тегов, их атрибутов и содержимого. Рассмотрим одну ноду: <tag attrib_1=”value_1” attrib_2=”value_2”>content</tag> Здесь tag – тег, attrib_1 и attrib_2 – атрибуты тега tag, value_1 и value_2 – значения атрибутов attrib_1 и attrib_2 соответсвенно, content – содержимое тега определяемое началом тега (<tag>) и его концом (</tag>) В XML-файлах тоже есть комментарии, они являются многострочными, т.е. их необходимо закрывать. Открываются комментарии этим сочетанием “<!--”, закрываются “-->”. Приведу пример: <!-- Тут может быть Ваш комментарий] --> Также, в XML-файлах есть возможность добавлять внешние файлы операцией #include, но тут есть одна особенность: В дочернем файле (файл который вы добавили) нужно писать теги от ноды родительского файла. Как пример могу привести следующий листинг: Родительский файл
Как вы заметили, ноды наследуются друг от друга (tag_1 и tag_2 от node_1 и node_2), обязательно закрываются (в листинге использовался новый тип закрытия - <tag /> – его полезно применять когда содержимое тега отсутствует, ну и мы увидели цель листинга – использование внешних файлов. В дочернем файле мы не писали ни корневой элемент (root), ни строку объявления кодировки файла.
В скриптах игры используется такой язык программирования, как Lua. Следует отметить его особенности: Регистрозависимость – это означает, что слова “word” и “Word” будут разными, следует это уяснить раз и навсегда, иначе Вы можете долго искать свою ошибку. Динамическая идентификация типа переменной – это означает, что нам не нужно ассоциировать переменную с ее типом, интепретатор сделает это за Вас.Как понять “ассоциировать переменную”: Это значит, что одна переменная может воспринимать в различных ситуациях с различным типом. То есть имея переменную со значением 765 при математических выражениях (например: сложения) она будет воспринимать как integer (целочисленное значение), а при выводе переменной, допустим, в лог, она уже будет обрабатываться как string (строка) В Lua функции, по строению, отличаются от процедур только наличием оператора “return” в своем теле, остальное аналогично процедурам. А по смыслу, функции возвращают информацию движку (проверка, результат подсчета), а процедуры являются последовательностью команд (создание объектов). Давайте разберем код:
Code
-- Функция получающая 2 аргумента function listing_script(item, item_2) local actor = db.actor object = actor:object(item) return object end
Итак, первая строка в листинге является однострочным комментарием (“--”), есть еще и многострочные, начинаются они с “--[[“, а заканчиваются знаками “]]” Далее идет создание функции listing_script с двумя аргументами item и item_2, item_2 я создал специально для того, чтобы продемонстрировать передачу нескольких аргументов. Третья строка, начинающаяся с оператора local, будет объявлением локальной переменной объекта (эта переменная будет недоступна для внешних обращений, т.е. для внешних функций), за ней идет простое объявление переменной object, которая вернет Булево значение (true - истина, false - ложь) в зависимости от наличия предмета, переданного в первом аргументе, у ГГ. Также стоит отметить, что db.actor – вызов функции actor из файла db.script, синтаксически это показано точкой. Двоеточие же в actor:object() говорит о том, что вызывается метод класса actor (функция, с помощью которой можно обращаться к параметру класса). Ну и последняя функция вернёт наше true или false туда, где функция вызывалась. Пример, local a = listing_script("af_medusa"). Переменная “a” будет истинной, если у героя есть артефакт "Медуза" (af_medusa). Теперь касаемо использования этих самых скриптов в игре S.T.A.L.K.E.R.: Глобальные функции и процедуры хранятся в файле _g.script – Глобальность этих функций состоит в том, что их можно использовать не вводя имя файла. Функции для использования из логики объектов хранятся в файле xr_conditions.script – Их используют в логике со специальными знаками: “!” - отрицание (то есть неравно) и “=” - равно Проверка организуется в фигурных скобках (“{” и “}”), приведу пример на основе того-же скрипта из листинга: “{=listing_script("af_medusa")}”. Условие выполнится только если у ГГ будет артефакт. Процедуры для использования из логики объектов хранятся в файле xr_effects.script – Их используют из логики со знаком “=” Использование процедур организуется знаками процента (“%”), приведу пример (скрипта нету, ну ладно, главное показать использование): “%=spawn_object("af_medusa") =spawn_object("wpn_pm")%”. Тут будут выполняться сразу 2 процедуры spawn_object с разными аргументами, конечно-же можно использовать и разные процедуры. Использование нескольких процедур будет аналогично использованию нескольких функций.
Остальные скрипты можно писать в любом файле (можно создавать и свои) и их использование будет следующим: <имя_файла>.<имя_функции|имя_процедуры>(<передаваемые_аргументы_если_есть>) Обратите внимание, что при вызове функций и процедур из диалогов невозможно передавать аргументы, т.е. вызов будет следующим: <имя_файла>.<имя_функции|имя_процедуры> Об lua можно подробно почитать на оф. сайте
С этим файлом возможно работать только после его декомпиляции perl-утилитой ACDC. Для работы ACDC необходимо установить библиотеку AcrivePerl. Мало того, что для каждой игры необходима своя версия утилиты, так ее еще и правят под свои нужды моддеры, но есть выход – Universal ACDC. Сия утилита способна распаковать любую часть игры, а также подавляющего большинства модов. Ей мы и будем пользоваться. После декомпиляции мы получим по два файла к каждой локации (alife – хранящим в себе все спавн-элементы игры и way, содержащим в себе точки путей для объектов), “all.ltx” – связывающий файл для последующей компиляции, “section4.bin” – хранящий в себе графпоинты игровых локаций, “section2.bin”
В этих файлах хранятся текстуры игры. В файлах вида название_текстуры_bump.dds хранятся карты высот. Они отвечают за реализацию эффекта рельефности на плоскостях (поподробнее о bump-mapping’e). Файлы вида название_текстуры_#bump.dds хранят карты бликов, отвечающие за интенсивность отражения света поверхностью. Чаще всего одному объекту соответствуют две или три текстуры.
В этих файлах хранятся все ролики игры. Стоит учесть, что эти ролики идут без звуков, звуки к роликам присоединяются в игре самостоятельно (по ранее указанным наводкам в конфигах).
В этих файлах соотносятся параметры для текстур (такие как: бампы, материал, шейдер...). Создать их можно только в ActorEditor
Распространенный аудио формат файлов в играх. Многие конвертеры с ним справляются, но нам нужно перегонять в формат WAV, с которым справляются все приличные конвертеры. Зачем перегонять в WAV если игра читает только OGG? Как уже писалось выше – Нам необходимо выставлять параметры в SDK, чтобы звуки правильно обрабатывались игрой, а SDK понимает только “вавки”.
Эти 0 пользователя(ей) поблагодарили STANDBUY за это полезное сообщение:
Для упрощения задачи мы будем использовать S.T.A.L.K.E.R. Icon Editor 0.6.3 (SIE), скачать его можно здесь Итак, запускаем программу и открываем файл (File → Open → mod_gamedata\textures\ui\ui_icon_equipment.dds) из которого мы будем брать иконку объекта, после открытия первого файла открываем наш (File → Open → gamedata\textures\ui\ui_icon_equipment.dds). В итоге мы имеем две вкладки: Первая - файл с необходимым нам ресурсом, а вторая - Наш файл). Переходим в первую вкладку и выделяем интересующую нас иконку, затем жмем правой кнопкой по выделенному участку и жмем “Копировать”. Переходим во вторую вкладку, ищем свободный участок под скопированную иконку, щелкаем правой кнопкой и выбираем “Вставить”, затем окончательно подгоняем иконку на положенное ей место и щелкаем ЛКМ. Для получения координат положения иконки выделяем ее, жмем ПКМ и выбираем “Информация о выделении...”. Выведется отдельное окошко с необходимыми нам данными, которые затем нужно будет подставить в секцию предмета. Сохраняем наш файл и всё готово
В игре запоминаем название предмета, для примера будем искать “Хлеб”. Итак, выходим из игры и запускаем NotePad++\SublimeText2 и нажимаем хоткей “ctrl+shift+f”, который запустит нам “Поиск по файлам”. В строку поиска вводим наш предмет в тегах text – будет выглядеть вот так: “<text>Хлеб</text>” (можно искать и без тегов, но тогда вы получите больше мусора), где искать указываем “configs\text\rus\” и нажимаем “Поиск”. Итак, мы нашли ноду:
Нам нужен отсюда идентификатор – st_bread, копируем его и ищем далее: В строку поиска вводим наш идентификатор (st_bread), где искать: Персонажей – configs\gameplay Артефакты, квестовые предметы, приборы, детекторы, броню – configs\misc Оружие – configs\weapons
Но, если вы не можете найти ID в этих папках – Ищите по всей папке configs. Также полезность: Если вы используете для поиска редактор с поддержкой регэкспов (т.е. регулярных выражений) то можете искать для: Персонажей – <name>ID</name> (регэкспы не нужны, поэтому подойдет для всех редакторов) Предметов – name\s+\=\s+ID (тут пошел простой регэксп “\s+” обозначающий повторение любого пробельного символа) Вот Вы и нашли свой драгоценный файл, теперь для: Предметов – Листайте файл вверх, ища секцию этого параметра (у нас это “bread”) Неписей – Ищите родительскую ноду “specific_character”, найдя ее, посмотрите на значение аттрибута id – это и есть, то, что Вы искали.
Также, у той-же ноды “specific_character” есть дочерний тег supplies, содержащий предметы в инвентаре NPC (также посмотрите содержимое файлов, что добавлены инклюдом) Возможно, найдя NPC вам потребуется файл его логики, что-ж, ищем дальше. Различают два вида подключения логики к NPC: Через смарт-террейн и через спавн-секцию, к сожалению, узнать из игры как подключен NPC можно только дедукцией Шерлока Холмса, поэтому пробуйте два: Смарт-террейн. Логика неписю присваивается посредством проверки “тот или не тот NPC”, поэтому искать будем эту самую проверку с необходимым нам аргументом. Найденный файл и есть его логика:Что: check_npc_name(ID); Где: configs\scripts\ Спавн-секция. Логика неписю присваивается посредством значения custom_data, в которой указывается путь к логике относительно папки configs. Поэтому будем искать ID непися в папке configs\creatures\С помощью регэкспов будем искать: character_profile\s+\=\s+ID
Вот наши поиски и окончились
Можно пойти 3-мя вариантами – Через SDK, через Milkshape, через HEX-редактор. Пойдем от наиболее правильного способа. X-Ray SDK Для того чтобы работать с моделью в SDK нам потребуется ее декомпилировать. Декомпилировать будем утилитой X-Ray game asset converter (11 jan 2012) Создаем папку, кладем в нее файл converter.exe из архива и копируем файл модели, текстуры которой мы хотим узнать\изменить. Создаем bat-файл (обычный txt файл с расширением bat), или-же запускаем командную строку, кому как удобнее. Я буду работать с батником, поэтому заполняю его:converter.exe -ogf -object <source_file>
Я буду работать с обрезом “wpn_bm16.ogf”:converter.exe -ogf -object wpn_bm16.ogf
Теперь запускаем батник и получаем нашу модель в формате object. Копируем ее в папку import установленного SDK (это необязательно, просто для удобства открытия). Открываем модель в ActorEditor из состава SDK 0.6 (да-да, 0.6 – это SDK 0.5 + Patch, делаем это из-за того, что SDK COP покорежит нашу модель при экспорте в OGF-файл, но если вы не собираетесь править текстуры, то это необязательно): File → Load → /import/wpn_bm16.object Если хотите использовать SDK младше 0.7 версии в WinVista, Win7 то следует дописать в батник запуска редактора параметр -editor Далее, смотрим раздел “Object Items” и в этом разделе открываем ветку “Surfaces”. В этой ветке хранятся все текстуры объекта, в моем случае она всего-лишь одна. Переходим на любой элемент ветки и смотрим значение параметра “Texture” – это и есть путь к текстуре. Чтобы его изменить нужно произвести двойной щелчок по строке (или нажать 1 раз на многоточие) и выбрать новую текстуру, но сначала их нужно еще и скопировать в папку gamedata вашего SDK. После всех манипуляций экспортируйте Ваш файл в формате OGF: File → Export → Export OGF... Ваше дело сделано, осталось воткнуть файл на его положенное место в Вашей папке мода. Анимации можно посмотреть в ветке “Motions” раздела “Object Items”. В этой ветке есть параметр «Motions Reference», который и содержит в себе ссылки на подключенные анимации. В том-же окошке можно подключать и свои анимации (с учетом того, что эти файлы есть в папке SDK\gamedata\meshes\).
MilkShape 3D Работать мы будем в MilkShape 3D 1.8.5b1 (в beta2 у меня вылет на рабочий стол при использовании плагина), а также плагин импорта\экспорта объектов S.T.A.L.K.E.R Программу необходимо зарегистрировать для использования плагинов, поэтому идем и регистрируемся (Help → About → Register) Итак, открываем наш файл File → Import → S.T.A.L.K.E.R.; Переходим в Tools → Model Information 1.7 Смотрим там ветку Material (Textures), из этой ветки выбираем один из материалов и смотрим параметр Diffuse Texture (обычная текстура), Alpha Texture (текстура канала прозрачности, вроде в игре не используются, т.к. это делается через обычную текстуру). Путь из этих параметров будет формироваться из содержимого файла xray_path.ltx, но Вы все равно определите относительный путь к текстуре. Если все-же Вы решили что-то поправить и сохранить текстуру – то экспортировать модель в SDK нужно через File → Export → S.T.A.L.K.E.R и указать имя сохраняемого файла с расширением object! Просмотр анимаций не предусмотрен.
HEX-Редактор Будем работать с программой WinHex 16, на примере артефакта af_blood.ogf Открываем модель с помощью этой программы (не забудьте ее зарегистрировать, а то Вы не сможете сохранять файлы весящие больше 200 кб) и ищем там строку “models\model” (это материал текстуры, в большинстве своем он указан как models\model). Найдя эту строку, смотрим не на нее, а на слова перед ней – От пробела (в хексе 00) до пробела перед models\model и будет написан путь к нашей текстуре. Изменять путь можно путем замены символов в существующем пути, т.е. Вы не должны изменить количество символов в пути, иначе вы сломаете модель и она не будет работать. Увидеть подключенные анимации можно в самом конце файла.
Эти 0 пользователя(ей) поблагодарили STANDBUY за это полезное сообщение:
Рассмотрим два способа. Первый будет получением координат в реальном времени (координаты будут выводиться на экран в игре), а второй будет выводиться к нам в новости (если чуть подредактировать скрипт, можно будет добиться того, чтобы он выводился еще и в файл). Способ #1 Находим в файле scripts/bind_stalker.script функцию actor_binder:update(delta) и добавляем в ее конец (перед словом end) название будущей функции: actor_pos() Получилось так:
Code
pda.fill_sleep_zones() actor_pos() end
Далее, добавим саму функцию в конец файла:
Code
function actor_pos() local lvid, gvid, pos, dir = db.actor:level_vertex_id(), db.actor:game_vertex_id(), db.actor: position(), device().cam_dir -- Объявление и назначение переменных local apos_string = string.format("lvid: %d gvid: %d pos: %1.6f, %1.6f, %1.6f dir: %1.6f, %1.6f, %1.6f\\n", lvid, gvid, pos.x, pos.y, pos.z, dir.x, dir.y, dir.z) -- Текст сообщения local hud = get_hud() local apos = hud:GetCustomStatic("apos_text") if apos == nil then hud:AddCustomStatic("apos_text", true) apos = hud:GetCustomStatic("apos_text") else apos:wnd():TextControl():SetText(apos_string) end end
Содержимое и обновление этого самого содержимого готово, осталось вывести его на экран. Лезем теперь в configs/ui/ui_custom_msgs.xml и добавляем в конец:
Разберем структуру последней вставки: Первая строка содержит информацию о блоке (фрейме), где будет храниться наш текст: x, y – Координаты верхнего левого угла фрейма для нашего текста Width, height – Ширина и высота соответственно, нашего фрейма Вторая строка содержит информацию о виде текста: Font – Название шрифта Rgba – Цвет текста в формате RGBA Align – Выравнивание (l\c\r) Второй способ более удобен в получении координат (конкретно для меня), поэтому пишем функцию аналогичную вышеприведенной:
Code
function actor_pos() local lvid, gvid, pos, dir = db.actor:level_vertex_id(),db.actor:game_vertex(),db.actor:position(), device().cam_dir local text = string.format(“position: %1.6f, %1.6f, %1.6f\\nlevel_vertex: %d\\ngame_vertex:%d\\ndirection: %1.6f, %1.6f, %1.6f”, pos.x, pos.y, pos.z, lvid, gvid, dir.x, dir.y, dir.z) news_manager.send_tip(db.actor, text, nil, "recent_surge", nil, nil) end
Функцию запишем в новый файл scripts/mod.script (можете воткнуть и в другое место, если разбираетесь) Далее, эту функцию нужно вызывать откуда-то... Давайте повесим обработчик на нажатие клавиши F6 в главном меню. Открываем файл scripts/ui_main_menu.script и ищем в нем следующие строки:
Code
if dik == DIK_keys.DIK_Q then self:OnMessageQuitWin() end
Добавим в конец этого условия (т.е. до end) следующие строки:
Code
elseif dik == DIK_keys.DIK_F6 and db.actor~=nil then self.OnButton_return_game() -- Выходим из меню mod.actor_pos() -- Вызываем функцию получения координат (actor_pos) из файла scripts/mod.script
Все готово, захотите получить координаты – заходите в игру, нажимайте ESC->F6 и координаты на экране.
Большинство параметров ГГ хранится в файле configs\creatures\actor.ltx; Давайте рассмотрим параметры защиты ГГ на разных уровнях сложностях. За это отвечают значения параметров секций вида actor_immunities_gd_(novice|stalker|veteran|master), чем они больше, тем больше урона получает ГГ. Давайте посмотрим, что за что отвечает:
Code
burn_immunity Термо-защита strike_immunity Гашение удара shock_immunity Электрозащита wound_immunity Защита от разрывов radiation_immunity Радио-защита telepatic_immunity Пси-защита chemical_burn_immunity Химзащита explosion_immunity Защита от взрывов fire_wound_immunity Пулестойкость
Также, посмотрим как изменить макс. переносимый вес ГГ: Для этого нам нужно 2 файла: файл взятый выше и файл configs\system.ltx В actor.ltx отредактируем параметр max_walk_weight который отвечает за максимальный вес при котором ГГ может двигаться, а в файле system.ltx поправим вес, который ГГ может таскать не напрягаясь, за это отвечает параметр max_weight
Лог-файл помогает нам узнать полезную информацию не только об фатальных ошибках, но и от простеньких ошибках, из-за которых игра даже не вылетает, но есть и еще одно использование, оно скорее статистическое – получение информации об размере использованных текстур (напрямую влияет на размер занимаемой ОЗУ компьютера), и скриптов мода. Найти лог-файл можно посмотрев файл fsgame.ltx который лежит в корне игры. За место сохранения там отвечает переменная $logs$ ($logs$ = true| false| $app_data_root$ |logs\), за путь к папке отвечает последние два участка (может быть и один, лучше опустите все true и false, и останется только путь к папке), здесь - $app_data_root$\logs\; смотрим выше на значение переменной $app_data_root$, у меня путь уже отредактированный, там просто написано users\, следовательно, путь к логам у меня будет таков: STALKER COP\users\logs\, т.е. в корне игры, что очень удобно. Вид вылета критического:
Code
Expression : Тип ошибки, обычно fatal error, что означает фатальная ошибка Function : Функция движка приведшая к вылету File : В каком модуле (движка) произошел вылет Line : Линия модуля движка с ошибкой Description : Описание ошибки Arguments : Основная информация о вылете, содержит информацию об ошибке мода, такие как файл в котором допущена ошибка, строка с допущенной ошибкой, объект или иные аргументы…
Мододелам, как правило более всего интересна последняя строчка arguments, но и из верхних строчек тоже можно выяснить информацию об вылете, поэтому часто требуют весь блок вылета. Например, несколько вылетов: Can't open section 'cost_wpn_ak74'-Движок не может найти секцию cost_wpn_ak74-Необходимо создать эту секцию, или же исключить ее использование Not enough storage is available to process this command.-Движку не хватает памяти для обработки команды-Оптимизировать компьютер, или же отредактировать скрипты приведшие к вылету scripts\sgm_blackday.script:119: attempt to index local 'g_selected_point' (a nil value)-В файле scripts\sgm_blackday.script на 119 строке идет попытка обратиться к переменной g_selected_point, а она неопределенна (равна nil)-Отредактировать скрипт, добавить проверки перед использованием Теперь несколько некритичных вылетов: ! Can't find texture 'amk\amk_ballon_texture'-Движок не может найти текстуру, поэтому будет использовать модель без текстур (модель будет темно-синей)-Добавить текстуру в мод, отредактировать объект который использует эту модель ! Unknown command: dump_infos-Командной консоли дали на обработку неизвестную команду-Удалить передачу этой команды Статистическая информация:
Строка 1 содержит информацию о занимаемой памяти ОЗУ процессом игры: free – Свободные килобайты ОЗУ reserved – В резерве кб ОЗУ committed – Занято движком кб ОЗУ Строка 2 содержит информацию о памяти выделенной на обработку текстур Строки 3 и 4 содержит информацию о занимаемой памяти на обработку информации\скриптов в игре: crt heap, process heap – Информация о куче (нераспределенная память) game lua – Выделенная память на обработку скриптов render – Выделенная память на рендеринг strings – Сэкономленная память на строчках smem – Сэкономленная память на совместно используемых скриптах\функциях
Эти 0 пользователя(ей) поблагодарили STANDBUY за это полезное сообщение:
Выражаю благодарность за проверку, корректировку, неоценимые поддержку и идеи при написании этой темы следующим Людям: Niafa, denis2000, Vaiteria, tracker, Hemul. Спасибо пользователям GeJorge и GEONEZIS за проверку текста с технической стороны вопроса. Выражаю благодарность также пользователю Spectr за то, что он запостил копипаст разбора содержимого папки SHOC\gamedata Неизвестного Автора - Неизвестному Автору, тоже Respect, за хороший пример разбора
Сегодня мы попробуем сделать ГГ бессмертным. Для этого нужно править всего один файл - actor.ltx в папке gamedata\config\creatures. Сама папка gamedata должна находиться в корне игры. Если таковой нету, то качаем распаковщик ресурсов для ТЧ, распаковщик ресурсов для ЧН и ЗП. Скачать его можно здесь и здесь Начнем. Первым делом мы должны изменить коэффициенты иммунитета для некоторых (или всех) сложностей игры. Например сделаем иммунитет для сложности Ветеран. Ищем в actor.ltx строчки: Код: [actor_immunities_gd_veteran] burn_immunity = 0.8 ;коэффициенты иммунитета strike_immunity = 0.8 shock_immunity = 0.8 wound_immunity = 0.8 radiation_immunity = 0.8 telepatic_immunity = 0.8 chemical_burn_immunity = 0.8 explosion_immunity = 0.6 fire_wound_immunity = 0.8
Теперь для закрепления бессмертия можно изменить в следующих св-вах: Код: [actor_condition] satiety_v = 0.000015 ;скорость уменьшения сытости со временем radiation_v = 0.0001 ;скорость уменьшения радиации satiety_power_v = 0.000055 ;увеличение силы при уменьшении сытости satiety_health_v = 0.0001 ;увеличение здоровья при уменьшении сытости satiety_critical = 0.0 ;критическое значения сытости (в процентах от 0..1) когда здоровье начианает уменьшаться radiation_health_v = 0.004 ;уменьшение здоровья при воздействии радиации morale_v = 0.0001 ;скорость восстановления морали psy_health_v = 0.001 ;скорость восстановления psy-здоровья alcohol_v = -0.0003 health_hit_part = 1.0 ;процент хита, уходящий на отнимание здоровья power_hit_part = 0.1 ;процент хита, уходящий на отнимание силы max_power_leak_speed = 0.0 ;накопление усталости (макс граница, до которой восстанавливается сила) в секунду игрового времени max_walk_weight = 65
bleeding_v = 0.0007 ;5 ;потеря крови при номинальной ране в секунду wound_incarnation_v = 0.001 ;0.003 ;скорость заживления раны min_wound_size = 0.0256 ;0.0256 ;минимальный размер раны, после которого она считается зажившей
И меняем эти свойства на эти: Код: [actor_condition] satiety_v = 0.000015 ;скорость уменьшения сытости со временем radiation_v = 1.0 ;скорость уменьшения радиации satiety_power_v = 0.0001 ;увеличение силы при уменьшении сытости satiety_health_v = 1.0 ;увеличение здоровья при уменьшении сытости satiety_critical = 0.0 ;критическое значения сытости (в процентах от 0..1) когда здоровье начианает уменьшаться radiation_health_v = 0.0 ;уменьшение здоровья при воздействии радиации morale_v = 1.0 ;скорость восстановления морали psy_health_v = 1.0 ;скорость восстановления psy-здоровья alcohol_v = -0.0003 health_hit_part = 0.0 ;процент хита, уходящий на отнимание здоровья power_hit_part = 0.01 ;процент хита, уходящий на отнимание силы max_power_leak_speed = 0.0 ;накопление усталости (макс граница, до которой восстанавливается сила) в секунду игрового времени max_walk_weight = 65
bleeding_v = 0.0001 ;потеря крови при номинальной ране в секунду wound_incarnation_v = 1.0 ;скорость заживления раны min_wound_size = 0.0256 ;0.0256 ;минимальный размер раны, после которого она считается зажившей
Сытость я решил не трогать, т.к. будет не интересно играть.
Эти 0 пользователя(ей) поблагодарили STANDBUY за это полезное сообщение: