Судьба Зоны: Ковыряемся в файлах

[Zander_driver 10 348]

Консольная команда движка СЗ, attach_adjust_mode, за пределами СЗ как-то вообще никого не заинтересовала Ну, и ладно.

Оставлю тут краткий инфо-справочник по ней, ибо функционал команды уже устаканился и меняться-дополняться видимо не будет. Может когда-то, кому-то, пригодится.

 

Включается просто - attach_adjust_mode 1 в консоль. Для выключения 0. Консольная команда доступна в движке СЗ начиная с версии 0.8.1.

Если команда включена, то можно редактировать любые предметы надеваемой экипировки, и любые оружейные аддоны.

Для этого редактируемый итем надо надеть/приаттачить, и выбрать, т.е. просто кликнуть по нему мышкой в том окне/слоте, инвентаря/окна кастомизации, где он находится.

Далее кнопками клавиатуры доступны следующие действия:

* * * Доступно для любых приаттаченных итемов и для любых оружейных аддонов * * *

[ A или D ] : + или - по оси X;

[ S или W ] : + или - по оси Y;

[ Q или E ] : + или - по оси Z;

[ R ] : Переключатель. Редактируем мы координаты <слота аттача> относительно родительского объекта, либо координаты итема/аддона относительно слота.

[ X ] : Переключатель. Будут ли нажатия WASDQE восприниматься как линейные-поступательные смещения, либо как вращения вокруг соответствующих осей.

[ Z ] : Устанавливает шаг поворота в 90 градусов.

[ numpad 7 или - ] : Уменьшает шаг смещения/поворота итема вдвое.

[ numpad 9 или + ] : Увеличивает щаг смещения/поворота итема вдвое.

[ B ] : Возвращает редактируемый итем в координаты 0,0,0, обнуляя все углы поворота и устанавливая шаг смещения и поворота в дефолтные значения.

[ P ] : Пишет в лог-файл текущие настройки.

* * * Доступно для ряда специфических классов объектов, имеющих доп.параметры * * *

[ numpad 6 или numpad 4 ] : Переключение канала редактирования в одну или другую сторону. Детали зависят от того что это за итем.

[ F ] : Включить/выключить итем.

[ Numpad 0 ] : Устанавливает шаг смещения, равный шагу регулируемого слота (Для планок пикатинни и т.п.)

* * * Доступно для окна кастомизации - команды управления оружием, к которому аттачатся аддоны * * *

[ numpad 8 или numpad 2 ] : Увеличить или уменьшить (и то и то - в 2 раза), скорость движений и поворотов оружия в зависимости от движений мыши.

[ numpad 5 ] : Вернуть оружие в исходные координаты и вернуть скорости к значениям по умолчанию.

[ V + мышь или скролл ] : Движение оружия от исходных координат. В том числе можно приближать хоть до отсечения модели плоскостью экрана, коллизии в этом режиме отключены.

* * * Кроме этого, в окне кастомизации оружия независимо от включения или нет attach_adjust_mode, доступно следующее:

[ мышь или скролл ] : Вращение рассматриваемого оружия по всем трем осям. Аналогично обзор со всех сторон доступен и в инвентаре тем же образом.

[ U ] : Переключение. Оружие показывается в 3D обзоре либо в руках ГГ.

[ T ] : Вкл/выкл прицеливания, для варианта с оружием в руках. Обычно ГГ целится правой кнопкой мыши) но т.к. мы находимся в ГУИ, это контекстное меню. А целиться через T.

* * * help * * *

[ H ] : Выведет в лог/консоль все то что я тут написал.

 

P.S. В ближайшем видео, буду это все показывать уже в действии И не только.

 

Изменено 5 Декабря 2021 пользователем Zander_driver
Добавил инфу о настройке пикатинни.

[Zander_driver 10 348]

Обновил Config Helper для версии 0.8.1

Там же теперь можно скачать актуальный lua_help для мода.

Только что, Alex TOPMAN сказал:

Что-то там комментарии совсем не про F1 и сохранение.

И что же с ними не так?

[Zander_driver 10 348]

8 минут назад, ~{MODoGEN}~ сказал:

Так это ж как раз по моей любимой лютой-жесть-хардкорно-обезбашенной теме!

Хм... У такой правки есть один минус.

Допустим ГГ зашел на локацию. Его кто-то увидел, прибежал, началась стрельба, прибежали остальные...

Допустим ГГ выжил.

К нему прибегали мобы со всей локи - значит на локации никого не осталось. Он пойдет дальше по пустой степи, где будет уже скучнее. Не уверен я, что это "хардкорнее". Скорее опять получается перекос баланса, где закрученные гайки соседствуют с скучной и легкой игрой на опустевшей локации. Где-то недавно я про такие контрасты уже писал...

[Zander_driver 10 348]

Технические новинки 0.8.2

В конфиге стволов и/или глушителей можно указывать
snd_shoot_subsonic - звук выстрела для дозвуковых боеприпасов.
(можно указывать snd_shoot_subsonic1, snd_shoot_subsonic2, и т.д. - без ограничения)

В конфиге патронов и снарядов можно указывать
subsonic_anyway = true/false. Если true, то этот боеприпас будет считаться дозвуковым всегда, игнорируя расчет скорости от длины ствола.

В конфиге патронов и снарядов можно указать
custom_snd_shoot - звук выстрела специфичный для именно этого боеприпаса.
(можно указывать custom_snd_shoot1, custom_snd_shoot2, и т.д.)
Если есть, то при использовании таких боеприпасов звук выстрела будет изменяться.

[Zander_driver 10 348]

Еще про технические новинки 0.8.2

В конфиги мутантов, добавляется поддержка нового параметра:

sound_die_headshoot = "звук смерти в случае хедшота"

А в конфиги неписей, соответственно

sound_death_headshoot = "звук смерти в случае хедшота"

Новые звуки опциональны. Если для кого-то их в конфиге нет, движок воспроизведет обычный sound_die/sound_death. А если есть - то будет использовать новые звуки при хедшотах.

 

В конфиги глушителей добавлен параметр

condition_per_shoot = износ глушителя за один выстрел. Запросто может не иметь ничего общего с износом собственно ствола. При крайнем износе, глушитель разрушается.

[Zander_driver 10 348]

Решил опубликовать исходники движка СЗ, версии 0.8.0

Это та версия, которая вышла в релиз в декабре 2020 года, полтора года назад.

Исходники предоставляются "как есть", без коммитов и без какой-либо документации) Кроме комментариев по коду.

Да, для желающих поржать и потыкать пальцем - напомню, это вообще-то мой первый проект на C++, я на нем учился методом тыка, проб и ошибок.

ссылка.

[Zander_driver 10 348]

Судьба Зоны. Квесты и сюжет [Гайд]

Часть 1-я

Скрытый текст

 

Окинув взглядом все сделанное за прошедшие годы, и озадачившись вопросом, что из этого более всего требует пояснений, гайдов, и вообще рассказа "А как оно черт побери работает". Я понял что это вовсе не оружейка, не торговля и не движок.

Больше всего отличается от оригинала (просто радикальным образом) - квестовая система. Вот о ней и пойдет рассказ.

Я не рассчитываю описать все различия в один присест, так что вероятно, будет гайд в нескольких частях. Ну, погнали...

 

 

Вступление. Общие представления.

Скрытый текст

 

Для начала, следует зарубить на носу правило - ВСЁ что вы ранее знали о создании квестов в сталкере, следует оставить за порогом Судьбы Зоны. Здесь всё иначе. Это не рекомендация, а именно правило - все старые, привычные в других модах, методы создания квестов, здесь не просто не актуальны - они не работают.

Вместо этого, здесь действует своя собственная система, написанная с нуля в 2014-2017 годах, с которой я читателя постараюсь познакомить.

Базовые понятия:

В СЗ, Квест - это скриптовый объект. Создание квестов происходит в скриптах на языке Lua. Это НЕ означает, что вам придется писать с нуля весь функционал потребный для квеста - нет и нет. В Судьбе Зоны действует группа скриптов для поддержания скриптовой квестовой системы, они обладают достаточно мощными возможностями, и чтобы создать новый квест, достаточно просто использовать готовую систему, которая выполнит подавляющее большинство квестовых действий автоматически. Тем не менее, желательно быть со скриптами на "ты", чтобы не буксовать на простейших вопросах. Так же полезно будет понимать принципы ООП (Объектно-Ориентированное Программирование)

В каждом квесте разработчик может сам выбирать, какой функционал ему потребуется.

Все квесты автоматически сохраняются и загружаются, в том числе сохраняя и загружая все кастомные данные, которые разработчик посчитал нужным добавить. Для этого ровным счетом ничего не нужно делать. Ограничений на количество сохраняемых данных в одном квесте, нет.

Таск_пойнт, он же иногда таск_реактор или таск_креатор. Живет в файле task_creator.script, но вам, если вы хотите создать квест, заглядывать туда вообще не потребуется. Там все давно отлажено и работает для любых квестов, настоящих или будущих. Таск-креатор - это условно, точка выдачи квестов, а так же выдачи наград за их исполнение. Это тоже скриптовый объект, тоже автоматически загружается и сохраняется. Они бывают двух типов: 1) Привязанные к уникальному нпс со стори_айди, 2) Привязанные к гулагу, в этом случае функции выдачи квестов и наград поручаются текущему лидеру гулага.

Таск_пойнт занимается составлением списка доступных квестов, чтобы показать его игроку. Созданием объекта квеста, если игрок взялся квест выполнять. И завершением/выдачей награды, когда квест завершился.

Заготовка квеста. Скриптовая таблица с некоторыми текстовыми, числовыми и прочими данными. Составленная таким образом, чтобы а) Этих данных было достаточно для старта собственно квеста (потребности определяются конкретным квестом), и б) Чтобы описание задания можно было показать в диалоге выбора заданий. Когда вы в игре подходите к квестовому нпс, выражаете ему желание подзаработать, он вам показывает именно заготовки квестов. Если ГГ выражает желание начать квест, заготовка передается в качестве аргумента, функциям создающим собственно квест. Иногда квест может стартовать не через диалог а иначе - в этом случае условие б) для заготовки не требуется.

Функциональное расширение, или библиотека функций - тоже скриптовый объект, со своими особыми функциями. Его можно добавить к объекту квеста, для расширения его возможностей. Есть разные функциональные библиотеки, как правило функции в них сгруппированы по назначению: Для взаимодействия с инвентарем, спавном, с ПДА, и другие. Разработчик может сам выбирать, какие функциональные расширения ему потребуется подключить. Подробнее об этих расширениях - далее.

 

Несколько подробнее, что такое в СЗ - квест. Из чего он состоит, и откуда берется.

Квесты создаются в файлах скриптов, имеющих названия по принципу subtask_XXX.script, где вместо XXX - класс квеста. Это важный момент.

Для примера разберем subtask_carrier.script - квесты на доставку посылок из пункта А в пункт Б.

В данном случае, Квест - объект класса subtask_carrier (описан в файле subtask_carrier.script). Данный класс унаследован от базового класса task_binder_default (описан в файле taskbind_default.script).

Данное определение наверняка поднимет бурю возмущения и негодования и вопросов, в обществе кодеров на языке луа, иногда именуемых скриптерами. Да, знаю, я тут кучу всего сказал "неправильно" - Луа не поддерживает наследование классов от других скриптовых классов, и переопределение методов классов, и в файле subtask_carrier.script, строго говоря, нет никакого определения класса.

И тем не менее, определение дано именно так, именно в такой формулировке. Чтобы дать (тем кто понимает принципы ООП) правильное понимание о том, как же оно на самом деле работает:

1) В taskbind_default.script определен базовый класс; Прародитель всех и вся квестов

2) Квестовая система СЗ, создав квест - первоначально создает объект этого класса.

3) В subtask_carrier.script разработчик может дополнить базовый класс своими переменными, и функциями (методами). А так же может переопределить методы класса родителя.

4) Квестовая система СЗ, пользуясь этими инструкциями, модифицирует созданный объект, изменяя и дополняя его методы при необходимости.

5) Так же квестовая система СЗ подключает к квесту все функциональные расширения, которые разработчик пожелал добавить. При этом, хотя они создаются как объекты своих базовых классов, их так же можно модифицировать, изменив или добавив какие-то методы и переменные уже этих функциональных расширений.

6) Квест готов к работе. Сохранению. Загрузке. Используя методы так, словно это объект класса (определенного в subtask_carrier.script), и наследующего от класса task_binder_default.

 

Разбор структуры файлов subtask_XXX.script

Скрытый текст

 

Какие самые главные переменные (свойства) есть в каждом квесте.

	self.id = -- уникальный числовой id квеста. Никогда не надо его устанавливать руками - системы СЗ сами это сделают. Его можно читать, и сравнивать с другими.
	self.file = -- Указание на файл квеста. Для subtask_carrier, здесь будет "carrier". Этот параметр указывает системе, в каком файле искать инструкции по модифицированию объекта квеста. Он так же устанавливается лишь единожды при создании квеста, и затем его никогда не надо менять.
	self.params = { -- Сохраняемые параметры. В эту таблицу можно добавлять любые числа, строки, в любом размере и количестве. ВСЕ ОНИ будут сохранены и загружены автоматически при сохранениях и загрузках игры.
		completed = 0, -- Состояние выполненности. Принимает значение 1, когда задание выполнено.
		failed = 0, -- Аналогично, принимает значение 1 когда провалено.
		file = _file -- Дублирует self.file - исторически так сложилось) 
	}

В каждом создаваемом классе квеста, можно все это дополнять своими параметрами. Располагая их внутри подтаблицы params, если вам нужно чтобы они сохранялись. Или вне ее, если сохранять их не требуется.

 

Какие ключевые функции обязательно (или не совсем), должны быть в файлах subtask_XXX.script:

function enabled(task_point) --- возвращает таблицу с несколькими потенциальными стартовыми данными.

Эта функция нужна в том случае, если квест будет выдаваться стандартным путем через диалог у квестового НПС. Таскпойнт, связанный с этим нпс, вызовет эту функцию (И передаст ей себя в качестве аргумента), а она должна сформировать и вернуть таблицу "заготовок" - пакетов данных, необходимых для отображения квеста в диалоге, и возможности его старта. Иными словами, функция формирует ответ на вопрос "А какие квесты (вот этого типа и для вот этого, переданного аргументом, таскпойнта) доступны сейчас?
Если квест стартует неким иным путем, то функция enabled в его файле не требуется.

function start(init_data)

Обязательная функция. Выполняет собственно старт квеста. В качестве аргумента ей передается "заготовка" квеста, та самая которую выбрал ГГ в диалоге с квестовым нпс. Либо если квест выдается не через диалог, то мы где-то вручную формируем ту же самую заготовку, и вызываем subtask_XXX.start(наша_заготовка)

Так же в файлах subtask_XXX как правило (но не обязательно) могут быть таблицы функций:

---описание методов которые надо переопределить для данного типа квестов
local re_define_base = {

В них указывается какие именно методы класса-родителя мы хотим изменить (Или добавить). В этих таблицах могут быть только функции, и при написании их следует помнить, что вызываться они будут исключительно как методы. Первым аргументом всегда передается self, т.е. ссылка на объект квеста. Затем уже другие аргументы если есть.

Там же далее могут быть re_define_items, re_define_pda, re_define_XXX etc... - Это списки переопределяемых для данного типа квестов, функциональных расширений. Изменять можно только те что к квесту подключены, конечно.

Ну и наконец, в конце файла как правило. Находится функция

function Create(Task_List, ID)

Она обязана называться именно так (ее будет вызывать квестовая система СЗ, передавая ей необходимые аргументы)

Тут ID это тот id, который новорожденному квесту назначен извне, системой. Менять его конечно не надо.

Вообще в этой функции делается очень много важного. И в своих собственных файлах subtask_XXX, лучше такую функцию скопировать из файла-соседа, и подправить под свои особенности. Разберем, что тут для чего:

function Create(Task_List, ID)
	if not (Task_List and ID) then abort("Некорректный вызов создателя заданий") end -- Проверка в целях безопасности.
	local flags = { -- Табличка flags указывает системе, какие функциональные расширения мы желаем подключить.
		items = true,
		spots = true,
		pda = true,
		sub = true,
		dialogs = true
	}
	Task_List[ID] = taskbind_default.task_binder_default(ID, "carrier", flags) -- создаем стандартный объект квеста. Вот здесь он собственно рождается.
	for k, v in pairs(re_define_base) do --- переопределяем его методы которые надо изменить
		Task_List[ID][k] = v
	end
	for k_, v_ in pairs(re_define_items) do --- переопределяем методы функционального расширения "items", которые надо изменить
		Task_List[ID].i[k_] = v_
	end
	-- И т.д., переопределяем методы всех подключенных функциональных расширений, Которые мы подключили и пожелали изменить.
end

 

 

 

 

* * *

Продолжение следует...

Изменено 9 Июля 2022 пользователем Zander_driver

[Zander_driver 10 348]

Судьба Зоны. Квесты и сюжет [Гайд]

Часть 2-я

Базовый класс квеста - task_binder_default. Разбираем, что там есть

Скрытый текст

 

Итак, что же собой представляет базовый класс квеста. Он работает наподобие биндера. В игре есть такая категория скриптовых объектов - биндеры, (например биндер актора находится в bind_stalker.script), в них есть определенный набор методов, которые движок игры вызывает при определенных событиях - сохранении, загрузке, получении урона и т.д.

Класс task_binder_default так же имеет определенный набор методов, которые вызываются при определенных событиях скриптовой системой СЗ. Расскажу о них по порядку.

Методы load и save вызываются при загрузке и сохранении квеста соответственно. Они уже включают в себя автоматическое сохранение и загрузку всех данных в таблице self.params, а также сохранение и загрузку всех функциональных расширений. Так что, я думаю что переопределять их никогда и ни для чего не понадобится.

Возвращаемые и принимаемые типы, там где есть, указаны синим курсивом.

on_start() - вызывается при старте задания.

bool has_my_item(int id) - с помощью этого метода можно проверить, относится ли итем(объект) с переданным id, к данному квесту.

complete() - выполнение условий задания, но не его завершение. К примеру, в задании "Убить 5 кабанов", этот метод будет вызван после убийства 5-го кабана.

fail() - стандартный провал задания. Вызывается в момент провала задания.

cancel() - Вызывается при отмене задания.

destroy_complete() - Выполняет завершение активного задания.

close_last() - Выполняет последнюю под-задачу в списке подзадач.

on_destroy() - вызывается при всех формах завершения задания. (провал/отказ/сдан успешно)

set_one_param(string kp, [string or number or table]vp) - Метод-обертка для установки значения сохраняемых параметров. kp - ключ, vp - значение. От простого присвоения self.params[kp] = vp отличается тем что автоматически суммирует время от текущей даты, если устанавливается метка времени, и автоматически обнуляет счетчик если устанавливается количество.

set_params(table params) - Метод принимает целую таблицу параметров. Обновляет и дополняет сохраняемые параметры квеста, полученной таблицей.

bool is_completed() - Проверка, выполнено ли задание. - возвращает возможность сдать задание

bool is_failed() - Проверка, провалено ли задание.

bool cancel_enabled() - Проверка, допускается ли для этого задания отмена.

update_hour(int h) - Апдейт задания, вызываемый 1 раз в игровой час. Вызывается в 00:00, 01:00, 02:00 и т.д. по игровому времени. В аргументе h передается, который час.

on_hour_update() - Вызывается после выполнения update_hour

int get_free_story_id() - Возвращает свободный story_id.

on_change_location(string old_loc, string new_loc) - Вызывается при переходе ГГ с одной локации на другую. В аргументах соответственно, с какой локации ушел и на какую пришел.

int relation_cost() - Возвращает репутационную оценку задания. По умолчанию для выполненного значение положительное, для проваленного отрицательное.

int cost(obj taskman) - Возвращает вексельную оценку задания. Входящий аргумент - квестовый НПС, который это задание выдал.

save_to_store() - Выполняет сохранение квеста в список выполненных/проваленных.

 

Это те методы, которые имеются у абсолютно любого квеста. В исходном либо переопределенном виде. Вроде и не мало, но те кто внимательно читал, наверняка заметили что тут явно не хватает многих нужных функций. Но это ведь не все) У квестов могут быть так же функциональные расширения. О них речь пойдет дальше.

 

 

Функциональные расширения. Что это такое и с чем их едят.

Скрытый текст

 

Как выше было замечено, некоторым квестам может потребоваться некий дополнительный функционал, кроме вышеописанного базового. Он реализован с помощью функциональных расширений квестов, эти расширения подключаются опционально. При создании квеста, разработчик в таблице flags указывает, какие именно расширения он хочет подключить (см. 1-ю часть, разбор структуры subtask_XXX)

Например: Создавая задание, разработчик решил, что неплохо было бы отображать его в ПДА. Для этого существует функциональное расширение task_pda, находится в файле task_pda.script. Менять в нем ничего не надо. Как его использовать:

1) в вашем subtask_XXX.script в функции Create, в таблице flags отмечаем pda = true, - так мы даем понять скриптам СЗ, что желаем подключить это расширение к квесту.

2) в вашем subtask_XXX.script в таблице re_define_pda ЕСЛИ НАДО - переопределяем методы функционального расширения.

3) Если какие-то методы расширения были переопределены, то в функцию Create добавляем в конец функции, обновление методов:

	for kp, vp in pairs(re_define_pda) do --- переопределяем его методы какие надо изменить
		Task_List[ID].p[kp] = vp
	end

4) В коде функций своего квеста, в subtask_XXX.script, можем использовать методы расширения, например таким образом:

local task_name = self.p:label() -- Здесь self.p это доступ к расширению ПДА. А :label() - вызов метода расширения.

В коде самого расширения, доступ к родительскому квесту выполняется так: self.parent ; К его хранилищу данных: self.parent.params ; к другому функциональному расширению и его методам - например так: self.parent.p:label() - так можно вызвать метод label() функционального расширения task_pda, из другого функционального расширения.

 

Аналогичным образом можно подключать другие функциональные расширения, если вашему квесту они нужны.

Какие они вообще бывают? Вот полный список на данный момент.

task_pda : файл - task_pda.script. Подключение: flags.pda ; Доступ: self.p ; Расширение занимается взаимодействием с ПДА ГГ, и отображением всей нужной информации там.

task_dialogs : файл task_dialogs.script. Подключение: flags.dialogs ; Доступ: self.d ; Расширение занимается взаимодействием с диалоговым деревом "Я к тебе по делу".

task_items : файл task_items.script. Подключение: flags.items; Доступ: self.i ; Расширение занимается квестовыми объектами. Это не обязательно инвентарные итемы - квестовыми могут быть и рестрикторы, НПС и т.д.

task_spots : файл task_spots.script. Подключение: flags.spots; Доступ: self.s ; Расширение занимается квестовыми отметками на карте, а так же спавном тех или иных объектов.

task_hits : файл task_hits.script. Подключение: flags.hits; Доступ: self.h ; Расширение занимается мониторингом хитов и убийств, которые причиняет ГГ в игровом мире.

task_subs : файл task_subs.script. Подключение: flags.subs; Доступ: self.u ; Расширение занимается подзадачами.

task_ways : файл task_ways.script. Подключение: flags.ways; Доступ: self.w ; Расширение занимается динамически генерируемыми путями. Это пути, по которым можно гонять нпс, и которые не требуется заносить в алл.спавн - их можно генерировать всякий раз при старте квеста.

*** Расширение task_ways пока не до конца отлажено. Пока единственное его применение, это стартовый обучающий квест с сопровождением Курьера, в ветке Дегтярева. Путь Курьера строится динамически.

 

 

Базовые методы функциональных расширений.

Скрытый текст

 

Есть определенный набор методов, которые есть у любого и каждого функционального расширения обязательно. Конечно эти методы можно переопределять в своих квестах. Вот они:

on_save() - вызывается при сохранении задания, и выполняет сохранение данных расширения, если надо.

on_load() - вызывается при загрузке задания, и выполняет загрузку данных расширения, если надо.

on_start() - вызывается при старте задания

on_complete() - вызывается при выполнении задания

on_fail() - вызывается при провале задания

on_cancel() - вызывается при отмене задания

on_destroy() - вызывается при завершении задания в любой форме (выполнено / провалено / отменено)

 

 

Подробное описание функциональных расширений и их методов.

Скрытый текст

 

Возвращаемые и принимаемые типы, там где есть, указаны синим курсивом.

Расширение task_pda. Список методов.

string, bool get_pointname() - Возвращает имя таскпойнта(работодателя), выдавшего квест, и bool - является ли он гулагом. true - это гулаг, false - это непись со стори_айди, nil - не удалось определить.

string menu_tag() - Возвращает стиль отображения квеста, в списке заданий в ПДА.

string label() - Возвращает заголовок (название) квеста.

string first_label() - Возвращает дата и место получения задания, для отображения в ПДА.

info() - Выводит в ПДА кастомное описание задания.

string time_message() - Подсчитывает сколько времени осталось на выполнение задания, и выводит результат в виде человекочитаемой строки.

[string] show_first_information() - возвращает или отображает в ПДА, базовое (сокращенное) описание задания.

show_status_information() - Отображает в ПДА применимые характеристики задания: Прогресс, оставшееся время, ценность награды, время текущее и когда задание должно быть завершено.

description(obj gui) - отображает в ПДА описание задания.

table: {int, int, int, int} get_label_color() - возвращает цвет шрифта, которым будет подписано задание в списке квестов в ПДА.

string header_tag() - возвращает стиль заголовка задания. В частности это влияет на отображаемые в изголовье описания квеста, картинки.

game_message(string msg) - Выводит в игре СМС c указанным текстом, к которому автоматически будет добавлена отметка, к какому заданию оно относится.

string get_positionlabel() - Возвращает человекочитаемое описание местности, в которой находится ГГ в момент вызова метода.

 

Расширение task_dialogs. Список методов.

bool dialog_active(int npc_id, mix_type param) - проверка доступа к определенной ветке диалога "Я к тебе по делу". Здесь npc_id - id собеседника, param указывает, к какой именно ветке запрашивается доступ. По сути этот метод переадресовывает precondition диалога, к коду квеста.

on_dialog(int npc_id, mix_type param) -- Выполнение действий в диалоговом блоке. Аргументы те же. По сути этот метод переадресовывает action диалога, к коду квеста.

 

Расширение task_hits. Список методов.

act_shoot(obj wpn) - Вызывается при каждом выстреле ГГ. В качестве аргумента передается объект оружия, из которого стрелял актор.

act_hit(obj obj) - Вызывается когда актор нанес кому-либо хит. В аргументе указывается, кому.

act_kill(obj obj) - Вызывается когда ГГ кого-то убил. В аргументе указывается, кого

bool check_object(obj obj) - Проверяет, подходит ли убитое существо под условия задания.

set_target(int mode, string sect, string comm, int count) - устанавливает целевые параметры задания. Кого, как и сколько бить.

 

Расширение task_items. Список методов.

Это расширение в частности, ведет учет всех игровых объектов причастных к данному квесту, и выполняет их удаление из игры при необходимости, когда квест завершен.

add([int or object] x) - Добавляет объект (указанный по id либо непосредственно), в реестр квестовых объектов, относящихся к данному заданию.

bool has_my_item(int story_id) - проверяет, относится ли объект с указанным story_id к этому заданию.

delete(string sect) - массовое удаление квестовых объектов по секции. Будут удалены все объекты, которые имеют указанную секцию, И относятся к этому заданию.

set_target(string sect, int count, [int v]) - Установка целей задания. Секция, количество. Необязательный третий параметр v позволяет назначить несколько целей. Например:

self.i:set_target("medkit", 5) -- актору поручено найти 5 аптечек.
self.i:set_target("af_medusa", 2, 1) -- кроме этого он так же должен найти две "Медузы"
self.i:set_target("bandage", 10, 2) -- И еще 10 бинтов. Задание будет выполнено когда он найдет ВСЕ позиции указанные через set_target.

clear() - выполняет удаление из игры всех объектов, относящихся к данному заданию.

bool check() - Проверка, собрал ли ГГ все нужные итемы.

int get_count(string sec) - возвращает количество итемов в инвентаре ГГ, с указанной секцией.

act_take(obj item) - Вызывается при получении итема в инвентарь ГГ

act_drop(obj item) - Вызывается при потере итема из инвентаря ГГ

transaction_take(obj agent, obj item) - Вызывается при получении итема в обмене (Тайник/торговля/др.). Здесь агент - объект с которым торгуем/взаимодействуем.

transaction_drop(obj agent, obj item) - Вызывается при потере(передача/продажа) итема в обмене (Тайник/торговля/др.). Здесь агент - объект с которым торгуем/взаимодействуем.

ammunition_item(obj item) - Вызывается при перемещении итема в разгрузку. В частности используется в обучающем квесте.

ammunition_use(obj use) - Вызывается при использовании итема из разгрузки. В частности используется в обучающем квесте.

on_physic_destroy(obj obj) - Вызывается при разрушении физ.объектов актором. Это те объекты, которые в принципе не могут быть живыми, и к ним неприменимо понятие "убить". Например, ящики.

 

Расширение task_spots. Список методов.

on_object_use(obj obj) - Вызывается при использовании НЕинвентарного физ.объекта. Когда ГГ наводит камеру на объект/рычаг/кнопку/дверь в игре, и нажимает "Использовать".

clear_task_spots(bool save_restr) - Очищает с карты все метки, установленные данным заданием. Параметр save_restr указывает, надо ли при этом сохранять рестрикторы, заспавненные для меток. При save_restr = false, они будут удалены.

object_spot(int obj_id, string spot_type, string text) - Постановка метки на объект с указанным id. Вообще, для постановки квестовых меток в СЗ, настоятельно рекомендуется использовать метод расширения, а не голые вызовы level.map_add_object_spotXXX. Потому что в данном случае, расширение task_spots устанавливает метку используя движковый метод level.map_add_object_spot_tag_ser - который так же маркирует метку как принадлежащую к данному конкретному заданию.

int get_free_story_id() - возвращает свободный индекс story_id

create_local_position( - Генерирует комплект координат для спавна чего-либо, соответствующие заданным условиям. Работает только на текущей локации.

     number min_dist, - минимальная дистанция от ГГ, в метрах

     number max_dist, - максимальная дистанция от ГГ, в метрах

     number item_dist, - минимально допустимая дистанция между заспавненными итемами

     int human_flag, - enum. Проверка территории стоянок НПС: 0 - не проверять; 1 - генерировать координаты только на территории стоянок; 2 - генерировать координаты только за пределами стоянок.

     int anom_flag, - enum. Аналогично, аномальные зоны: 0 - не проверять; 1 - только на территории аномальных зон; 2 - только вне аномальных зон.

     int target_count - сколько точек спавна необходимо создать.

) - Результаты своей работы, этот метод сохраняет в поля функционального расширения self.clv, self.radius, self.min_dist. Вообще этот метод скорее для "внутреннего использования" в самом расширении, маловероятно что когда-то потребуется его вызывать или переопределять в квестах.

Методы, описанные далее, выполняют спавн каких-либо объектов в игру. Все они возвращают результат, указанный как {spawn data} - это таблица следующей структуры:

{
	[1] = {int, int, ... , int}, -- Список id заспавненных объектов
	[2] = int -- Количество заспавненных объектов. (Да, избыточная инфа.. не спрашивайте почему) исторически так сложилось, давно. Переделывать лень, т.к. этот формат таблицы используется в куче скриптов СЗ, далеко не только квестовых)
}

Так же следует учитывать, что {spawn_data} может принимать значение nil. В том случае, если ни одного объекта заспавнить не удалось.

{spawn data} region_object_spot(int obj_id, string spot_type, string text, number radius) - Постановка "приблизительной" метки на объект. Будет заспавнен рестриктор с нулевым радиусом где-то поблизости от объекта указанного через obj_id, на расстоянии не более чем radius от него. И на этот рестриктор будет поставлена метка spot_type с указанным текстом. Излишне упоминать, что и здесь, и далее, все метки маркируются как принадлежащие к данному квесту.

 

{spawn data} parametric_spawn(         -- Параметрический спавн с набором условий
      number min_dist, - мин.дистанция от актора

        number max_dist, - макс.дистанция от актора

        number item_dist, - дистанция между под-пунктами спавна

        int human_flag, - см.выше(create_local_position)

        int anom_flag, - см.выше(create_local_position)

        int target_count, - число под-пунктов спавна: Метод сначала вычисляет ряд под-пунктов удовлетворяющих условиям, а затем уже спавнит указанные итемы (в т.ч. по несколько штук), в окрестностях найденных под-пунктов.
        [number or nil] wind_mode, - Тест на ветровую защиту: Все левел-вертексы в СЗ имеют маркировку защищенности от ветра. Она варьируется от 0.0 в чистом поле на вершине холма, до 1.0 в помещении в четырех стенах. Параметр wind_mode указывает, какие места искать: Положительное значение означает, что мы хотим ветрозащиту выше wind_mode, отрицательное значение означает, что мы хотим ветрозащиту ниже чем abs(wind_mode). nil означает - не выполнять тестирование по этому признаку.

        [number or nil] rain_mode, - Тест на дождевую защиту: Все левел-вертексы в СЗ имеют маркировку защищенности от дождя. Она варьируется от 0.0 в под открытым небом, до 1.0 под надежной крышей без дыр и щелей. Параметр rain_mode указывает, какие места искать: Положительное значение означает, что мы хотим дождезащиту выше rain_mode , отрицательное значение означает, что мы хотим дождезащиту ниже чем abs(rain_mode). nil означает - не выполнять тестирование по этому признаку.

        [int or nil] close_mode, - Тест на ограниченные участки АИ-сетки. С каждым вертексом АИ-сетки сопряжено от 1 до 4 соседних вертексов. Как правило 4 бывает в чистом поле без каких-либо препятствий и укрытий поблизости. 2-3 - возле стен, 1 - в каких-то тупичках и закоулках. Параметр close_mode указывает, какие места искать: Положительные значения указывают что мы хотим, чтобы в найденных точках АИ-сетки сопряжение с соседними вертексами было выше указанного. Отрицательные значения - что мы хотим сопряжение АИ-сетки ниже чем abs(close_mode). nil - не выполнять тестирование по этому признаку.

        [number or nil] anom_mode, - Тест на попадание в аномалию (любую). Отрицательные значения означают, что итемы надо заспавнить внутри шейпа аномалий. Положительные - снаружи. Число в данном случае выражается через радиус срабатывания аномалии. К примеру, anom_mode = 2.5, означает что мы хотим спавнить объекты так, чтобы каждый из них был от ближайшей к нему аномалии не ближе, чем в двух с половиной радиусах ее срабатывания. С помощью комбинирования этого параметра и anom_flag = 1, можно спавнить объекты в аномальных зонах, не попадая в аномалии.

        int points_count, - сколько всего надо итемов/объектов заспавнить.
       string section, - что спавнить.

       [string or nil] cust, - что записать в кастом-дату каждого заспавненного объекта

       bool poor_task_items, - Регистрировать ли заспавненные объекты как квестовые (требуется подключенное расширение task_items). Если true, все заспавненные объекты будут удалены по завершении квеста.

       [string or nil] spot_type, - метка на объектах. nil - не ставить метку.

       string spot_text -текст метки
    ) - Применяя метод parametric_spawn, следует помнить что это довольно "тяжелая" функция. Не стоит ее вызывать для спавна огромного множества предметов, так же не ленитесь проставлять nil в параметрах тестов (wind_mode, rain_mode, close_mode, anom_mode) - если тестирование по этим признакам вам не нужно, это поможет сэкономить время ЦП при спавне.

 

{spawn data} taskspawn( -- Спавн квестовых предметов с грубо заданными условиями // Работает быстрее, чем параметрический.

        number min_dist, - мин.дистанция от актора

        number max_dist, - макс.дистанция от актора

        number item_dist, - дистанция между под-пунктами спавна

        int human_flag, - см.выше(create_local_position)

        int anom_flag, - см.выше(create_local_position)
    int target_count, - количество предметов

    int target_section, - что спавнить

    int spot_text, - текст на метке (будет автоматически установлена "приблизительная" метка на область спавна/поиска)

    int reserve_count - количество запасных итемов. Например, при спавне датчиков по квесту, их спавнится больше чем требует квест.
    )

{spawn data} simple_ready_spawn(table of {int gv, int lv, vector3 pos} elements ready_coord_table, string section, [string or nil]cust, [string or nil]spot_type, string spot_text, bool poor_task_items) - Простейшая функция спавна объектов в заранее заданные координаты. Принимает таблицу, состоящую из элементов вида {int gv, int lv, vector3 pos}, где каждый элемент - координаты спавна. Спавнит объекты указанной секции, пишет им в кастом-дату указанное, ставит на них метку (если указано), подписывая ее названием квеста, если указано poor_task_items = true, то регает заспавненное в реестр с тем чтобы по завершении квеста удалить.

{spawn data} spotted_spawn_items(int lv, number radius, number min_dist, int tcnt, string section, [string or nil]cust, [string or nil]spot_type, string spot_text, bool poor_task_items) - Еще одна простейшая функция спавна объектов. В окрестностях левел-вертекса № lv, в радиусе не далее radius от него, на расстоянии не менее min_dist друг от друга, рандомно набрасывает координаты спавна в количестве tcnt точек, и спавнит в них объекты указанные в section, записывая им в кастом-дату указанное в cust, ставя на (местность спавна) приблизительную метку spot_type (nil - нет метки), подписывая метку текстом указанным в spot_text, и регистрируя заспавненное в реестр с тем чтобы по завершении квеста удалить, если poor_task_items = true.

 

* * *

Продолжение следует...

Изменено 9 Июля 2022 пользователем Zander_driver

[Zander_driver 10 348]

Судьба Зоны. Квесты и сюжет [Гайд]

Часть 3-я

Функциональное расширение для управления подзадачами.

Скрытый текст

 

Расширение task_subs. Занимается квестовыми подзадачами. Для работы этого расширения, так же обязательно должно быть подключено расширение task_pda (впрочем, если разраб забыл это сделать - подключит автоматически).

При взгляде на код в этом файле, можно заметить что там два класса. task_sub_control - это собственно функциональное расширение, управляющее подзадачами. task_sub_item - это подзадача. Ее дальше тоже разберем. Пока стоит оговориться, что в СЗ, подзадачи - это немного бОльшее, чем принято считать в сталкере. Это интерактивный элемент, который в числе прочего можно использовать для отображения под-пунктов задания, их состояния выполнено/не выполнено/провалено, и т.д., но подзадачи годятся так же и для другого. Их можно использовать как раскрываемый спойлер с содержимым внутри контентом, или ссылку на некий сторонний контент.

А пока методы расширения task_subs.

int add_info( - Добавляет к квесту подзадачу. Возвращает уникальный (для данного квеста), id подзадачи.

     string tag_, - визуальный шаблон оформления подзадачи. Какие они бывают, можно посмотреть в файле config/ui/pda_content.xml, там же можно и новые добавить.

     string head_, - Заголовок подзадачи. Это может быть транслируемый текст или пустая строка.

     string content_, - Текст подзадачи. Содержимое, отображаемое если подзадачу раскрыть. Это может быть транслируемый текст или пустая строка.

     string img_, - Картинка подзадачи. Здесь писать texture_name (если нужный кусочек текстуры зареган где-то в xml), либо просто адрес файла текстуры. Для случая когда не нужна никакая картинка - пишем "empty_texture" - это имя в СЗ носит текстура у которой все RGB-пиксели черные, а альфа-канал абсолютно прозрачный.

     string url_, - Ссылка на контент. Может быть пустой строкой (ссылка отсутствует). Если тут строка не пустая, то по клику на данную подзадачу ПДА выполнит переход к указанному в ссылке контенту. Подробнее о механизме ссылок будет далее.

     string geo_ - Геолокация. Механизм геолокаций пока недоработан.

)

set_info_tag(int id, string tag) - Установить шаблон подзадачи с указанным id.

set_info_head(int id, string head) - Установить заголовок подзадачи с указанным id.

set_info_content(int id, string content) - Установить содержимое подзадачи с указанным id.

set_info_img(int id, string img) - Установить картинку подзадачи с указанным id.

set_info_url(int id, string url) - Установить ссылку подзадачи с указанным id.

set_info_geo(int id, string geo) - Установить геолокацию подзадачи с указанным id.

show_custom_info() - Отображает весь список подзадач в окне ПДА

delete_info(int info_id) - Удаляет подзадачу с указанным id.

 

Про визуальные шаблоны в pda_content.xml - Общее описание, что есть что и для чего.

	<tasklist_subimage_default x="8" y="8" width="300" height="18"> <!-- собственно визуальный шаблон подзадачи. Чтобы его использовать, в скриптах надо указывать его имя - "tasklist_subimage_default" -->
		<head x="0" y="0" width="300" height="18" stretch="1"> <!-- заголовок. Обязательный элемент. -->
			<auto_static x="0" y="0" width="18" height="18" stretch="1">
				<texture stretch="1">ui_taskpda_glyph_attention</texture> <!-- Иконка подзадачи. Ее нельзя изменить скриптами, только тут в конфиге. -->
			</auto_static>
			<text font="letterica16" r="200" g="200" b="220" x="19" y="0" complex_mode="1" align="l"></text> <!-- Текст заголовка. Это его изменяет метод set_info_head -->
		</head>
		<body x="0" y="128" width="300" height="30" stretch="1"> <!-- Контент подзадачи. НЕ обязательный элемент. Скрывается/раскрывается по клику на заголовок -->
			<text x="0" y="0" font="letterica16" r="180" g="180" b="180" complex_mode="1" align="l"></text> <!-- Текст контента, устанавливается методом set_info_content. При необходимости, движок автоматически увеличивает текстовое поле с тем чтобы текст в него поместился. -->
		</body>
		<image x="0" y="18" width="300" height="110" stretch="1"> <!-- Картинка. Необязательный элемент. -->
			<texture stretch="1">empty_texture</texture> <!-- Вот эту текстуру изменяет метод set_info_img -->
		</image>
	</tasklist_subimage_default>

 

Класс task_sub_item - квестовая подзадача.

Скрытый текст

 

Находится в том же файле task_subs.script, чаще всего используется для классических "подзадач" в квестах, но может не только это. Вообще это просто удобный интерактивный визуальный элемент для организации и структурирования информации в квестах.

Подзадачи так же автоматически сохраняют и загружают свое состояние, ничего делать для этого не требуется.
Доступ к подзадаче выполняется через функциональное расширение подзадач. Например:

self.u.subs[sub_id]:tag(data) -- Это доступ из родительского квеста. 
--/ Квест / Расширение подзадач / Список подзадач / Подзадача с индексом sub_id / вызвать у нее метод tag, и передать ему аргумент data.
if self.parent.u then -- Проверим, что расширение подзадач подключено к нашему квесту
	self.parent.u.subs[sub_id]:tag(data) -- А это доступ из другого функционального расширения.
  	--/ Расширение / Квест-родитель / Расширение подзадач / Список подзадач / Подзадача с индексом sub_id / вызвать у нее метод tag, и передать ему аргумент data.
end

Методы подзадач:

clear(userdata store) - очистить свои данные из указанного хранилища

on_save(userdata store) - сохранение

on_load(userdata store) - загрузка

on_load_up(userdata store) - загрузка со смещением на 1 индекс

tag(string data) - установить таг (шаблон)

head(string data) - установить заголовок

content(string data) - установить контент

img(string data) - установить картинку

url(string data) - установить ссылку

geo(string data) - установить геолокацию

view() - отобразить подзадачу в окне ПДА.

Можно заметить, что все они либо уже продублированы (обернуты) в методах расширения task_subs, либо предназначены для автоматического вызова. Так что я думаю, в большинстве случаев никому и не потребуется получать доступ к отдельной подзадаче и дергать ее методы. Все нужное умеет делать уже само по себе расширение подзадач task_subs.

 

 

Функциональное расширение task_way. Динамические пути.

Скрытый текст

На данный момент, (лето 2022), все еще находится в разработке и тестировании. По замыслу, расширение должно управлять динамическим (in_game) созданием, поиском подходящих, и удалением путей. Необходимый функционал со стороны движка уже большей частью реализован, пути в СЗ необязательно регистрировать в all.spawn - их можно создать прямо в процессе игры, а затем удалить когда надобность в них отпала. Пока единственный квест, использующий этот функционал - стартовый обучающий квест, ветка Дегтярева, сопровождение Курьера. Его путь генерируется динамически. А в виде функционального расширения, эти возможности пока не готовы.

* * *

Продолжение следует...

Изменено 9 Июля 2022 пользователем Zander_driver

[Zander_driver 10 348]

А что это у нас тут?

А тут генератор пароля для демо-рекорда "Судьбы Зоны".

ссылка

Инструкция в архиве.

[Zander_driver 10 348]

20.02.2023 в 11:51, Earth2Space сказал:

Если раньше проход был перекрыт, то значит всё, судьба.

А вопли про непроходимые Лиманск, Дикую Территорию, и обожемой аномалия на входе к Сидоровичу, мы уже не помним, да?

И кто те вопли громче всех издавал.

Я лишь повториться могу - если не нравятся механика аномалий, аномальных цепей, сами аномалии в конце концов - то вам просто не сюда. Есть же куча других модов, таких где зона без аномалий вообще, или там их 2-3 штуки по сюжету. Ах да у них там и сюжет есть.

Тут правила свои. И просьбы в духе "сделайте из СЗ - оригинал ТЧ", или "сделайте из СЗ солянку/оп/nlc/другой мод по вкусу" - услышаны никогда не будут. Для удовлетворения таких просьб существуют оригинал ТЧ, солянка, оп, и т.д.

[Zander_driver 10 348]

30 минут назад, Earth2Space сказал:

И мне вообще фиолетово кто тебе когда и что вопил.

Мне тоже. Просто забавно что ты же и вопил.

30 минут назад, Earth2Space сказал:

И я никого ни о чём не просил, а задал вопрос как сделать по-другому.

В файле foz_new_anoms.script, начиная с строки 677, есть такой фрагмент кода:

	if base_sec.rd < 0.45 or base_sec.wd < 0.45 or (level.vertex_fwall(lv) < 4 and level.vertex_fwall(lv) ~= -1) then
		return foz_new_anoms.create_anomaly_timed(base_sec, pos, lv, sp_data, lv_config)
		-- Позже с развитием формата FOZ#AI, доработать эту проверку.
	end

Закомментируй его весь, от if base_sec до закрывающего end. (Поставить -- в начале каждой строки).

Жаловаться что после этого подземки снова стали непроходимыми, не надо.

[Zander_driver 10 348]

Дополнения возможностей интерфейса, доступные начиная с версии 0.8.2

О чем речь? О xml-конфигах интерфейсов, любых. Добавлены возможности их позиционирования.

// было с оригинала: (Все координаты читались так, будто у пользователя экран 1024 х 768 pix)
x - положение по горизонтали
y - положение по вертикали
width - ширина
height - высота

// Добавлено в 0.8.0
as_is - Может быть 0 либо 1. Если 1, то параметры width & height воспринимаются в пикселах реального монитора конечного юзера. Сохраняя пропорции и не растягиваясь.

// Добавлено в 0.8.2

left , right , top , bottom - Действие этих параметров аналогично их смыслу в CSS. Определяют отступ слева,справа, сверху, снизу, от края родительского элемента. Если есть, то имеют приоритет над выше-указанными x и y.

r_width , r_height - Определяют ширину и высоту в процентах от ширины и высоты родительского элемента. Если есть, то имеют приоритет над выше-указанными width и height.

z_index - Определяет порядок отображения элемента, так же как в CSS, допустимые значения для X-Ray от 0 до 254. (По умолчанию 0).

Изменено 10 Марта 2023 пользователем Zander_driver

[Zander_driver 10 348]

1 час назад, waha40k6 сказал:

нет у меня файлов config\ph и config\setg 

Это не файлы, а папки.

1 час назад, waha40k6 сказал:

Как уменьшить спавн мутантов а то при новой игре воткнул на максимум

Начать Новую Игру, и настроить НЕ на максимум.

В актуальной на данный момент, версии мода, спавн мутантов регулируется только настройкой в главном меню при старте Новой Игры. Конфиги на это не влияют, и изменить настройку уже в процессе игры нельзя.

P.S. Возможно, изменение настроек спавна в процессе игры, будет разрешено в версии 0.8.2, которая сейчас готовится.

[Zander_driver 10 348]

Начиная с версии 0.8.2.14 (ЗБТ), или 0.8.2 (ОБТ / Релиз), в СЗ появляется своя собственная система сигналов.
Как к ней подключаться:

Скрытый текст

 

1) Находим в папке скриптов, файл addon_register.script, а там - функцию init

function init()
-- подключение модулей
local list = {
    'habar',
    'foz_fixes',
        --- Вписать свой скрипт сюда.

2) В своем файле скрипта с правками для СЗ
 

-- создаем функцию init:
function init()
      signals.register("группа.событие", ваш_файл.ваша_функция)
      -- Регистрируем подписку на события для всех своих функций.
end

3) Посмотреть, какие бывают группы и события, можно (будет) в signals.script

--[[
	Система предназначена для упрощения подключения сторонних правок, затрагивающих скрипты, к моду Судьба Зоны.
]]

local xlinks = {
	actor = { 		--********** события актора **********************************************************************************************************************************************************
		net_spawn = {}, 					
		on_key = {}, 						--/ Кнопки
		on_key_free = {},
		on_key_hold = {},
		on_wheel_rotation = {},
		net_destroy = {},
		reinit = {},
		on_item_to_ammunition = {}, 		--/ Перемещение в слот-карман на разгрузке
		on_item_to_module = {}, 			--/ Перемещение в слот модуля
		on_custom_zoom_update = {}, 		--/ Изменение настроек прицеливания в окне кастомизации
		on_item_use_from_ammunition = {}, 	--/ Использование итемов из разгрузки
		on_cell_item_select = {}, 			--/ Выбор предмета в инвентаре
		on_transaction_take = {}, 			--/ Торговля и другие формы обмена с живыми НПС.
		on_transaction_drop = {},
		on_sync_complete = {}, 				--/ Завершение Клиент:Синхронизации
		on_sleep_begin = {}, 				--/ Сон
		on_sleep_final = {},
		Before_use_item = {}, 				--/ Перед использованием
		on_actor_weapon_jammed = {}, 		--/ Оружейное
		on_actor_weapon_reload = {}, 		--/ 
		on_actor_weapon_empty = {},
		on_actor_weapon_zoom_in = {},
		on_actor_weapon_zoom_out = {},
		on_actor_weapon_switch_gl = {},
		on_actor_heal = {}, 				--/ Лечение ГГ в окне медика
		on_pickup_item_showing = {}, 		--/ При появлении иконки итема, который можно подобрать
		Place_item_to_box = {}, 			--/ Обмен с ящиком/тайником
		take_item_from_box = {}, 
		take_item_from_corpse = {}, 		--/ Обмен с трупом нпс/моба
		place_item_to_corpse = {},
		Item_on_ruck = {}, 					--/ Перемещение из слота в рюкзак
		Item_on_slot = {}, 					--/ Перемещение в слот
		hit = {}, 							--/ Базовые события
		death = {},
		info = {},
		save = {},
		load = {},
		use_object = {},  					--/ Использование объекта
		on_item_take = {}, 					--/ Любое получение/потеря предметов.
		on_item_drop = {},
		update_sec = {}, 					--/ апдейты с высокими интервалами. ~ 1 сек.
		update_5sec = {}, 					--/ ...и ~ 5 сек.
		kill = {}, 							--/ Actor кого-то убил.
		ph_destroy = {}, 					--/ Actor разломал какой-то физ.объект
		task_start = {}, 					--/ Старт квеста
	},
	ui = { 		--****************** события UI **********************************************************************************************************************************************************
		inv = {}, 			--/ Инвентарь
		inv_close = {}, 	
		trade = {}, 		--/ Торговля
		trade_close = {},
		box = {}, 			--/ Обыск тайника/трупа
		box_close = {},
		talk = {}, 			--/ Диалог
		talk_close = {},
		pda = {}, 			--/ ПДА
		pda_close = {},
		medic = {}, 		
		medic_close = {},
		hacker = {},
		hacker_close = {},
		technic = {},
		technic_close = {},
		customwpn = {}, 	--/ Кастомизация оружия
		customwpn_close = {},
		qte = {}, 			--/ Q.T.E.
		qte_close = {},
	},
	npc = { 	-- **************** события нпс **********************************************************************************************************************************************************
		reinit = {},
		net_spawn = {},
		net_destroy = {},
		on_transaction_take = {},
		on_transaction_drop = {},
		hit = {},
		use = {},
		item_delete = {}, 	--/ Событие удаления итема из инвентаря нпс. Аналогично item_drop, но в данном случае серверный объект соответствующий потерянному итему, УЖЕ не существует.
		item_drop = {},
		item_take = {},
		save = {},
		load = {},
	},
	monster = { --************ события монстров **********************************************************************************************************************************************************
		use = {},
		waypoynt = {},
		death = {},
		hit = {},
		net_spawn = {},
		net_destroy = {},
		save = {},
		load = {},
		update_5sec = {},
	},
	game = { 	--**************** события игры **********************************************************************************************************************************************************
		start = {}, 				--/ Старт Новой Игры
		version = {}, 				--/ Изменение версии (патча)
		change_location = {}, 		--/ Смена локации
		on_midnight = {}, 			--/ Вызывается каждую полночь
		day = {}, 					--/ Начало дня (утро)
		night = {}, 				--/ Начало ночи (вечер)
		hour = {}, 					--/ Каждый игровой час.
	}
}

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

signals.register("actor.net_spawn", ваш_файл.ваша_функция)

 

Что все это дает - как очевидно, любые правки в области скриптов можно единожды подключить, и не заниматься адаптациями при обновлениях версий мода. Также, подключение и отключение любых сторонних дополнений затрагивающих скрипты, делается в одном файле addon_register.script путем добавления/удаления/комментирования единственной строки.

 

 

[Zander_driver 10 348]

18 часов назад, kot_123 сказал:

невозможно пройти с тёмной долины в промзону из за отсутствия шейдеров асфальта

Это исправлено еще при царе горохе. Как и прочее что вы упоминаете. В нынешней СЗ тестеры не встречают подобных проблем.

[Zander_driver 10 348]

2 часа назад, kot_123 сказал:

будет не меньше багов чем в предыдущей

Я вам больше скажу.

Будет БОЛЬШЕ багов! Во сто крат!

Ведь не может быть иначе, это всем известно.

Остается лишь вопрос, раз вам все это известно заранее, то зачем вы вообще сюда пишете? Можно же спокойно посыпать голову пеплом и тихо ползти куда-нибудь. Здесь ВАМ ловить нечего.

[Zander_driver 10 348]

5 часов назад, kot_123 сказал:

Люди вам пишут

Вы бы хоть признались для начала, что в тему раздела "Судьба Зоны" вы пишете по поводу вообще другого мода.

А то совершенно невозможно же понять, о чем вы вообще толкуете заявляя о наличии в СЗ таких багов, которых в ней нет уж много лет тому назад.

 

"Большая Зона" изначально не мой проект. Автор мода не я, и писать мне сюда по поводу проблем там - не очень имеет смысл. Пишите в тему "Большой Зоны".

Да, был момент когда я этим проектом какое-то время занимался, пытаясь привести его в порядок. Возможно такой момент будет и в будущем, тогда я постараюсь исправить там известные проблемы, о которых к тому моменту напишут там. Не тут.

Но надо понимать еще раз, что автор того проекта - не я. Для меня основной в сталкеро-моддинге проект - пока-что, "Судьба Зоны". А никак не БЗ. БЗ я занимался/буду заниматься постольку поскольку, в меру наличия лишнего свободного времени, оставшегося после разработки СЗ. Я уж молчу о том что кроме моддинга могут быть другие дела, на которые тоже нужно свободное время.

Вот как-то так. Такие дела.

 

[Zander_driver 10 348]

26 минут назад, ПЕШКА сказал:

создать шлем и модельку к нему для СЗ?

Для начала можно написать конфиг. Конфиги можно писать по образу и подобию существующих, шлемы в СЗ все лежат по адресу gamedata\config\inv\equipment\head

Большинство параметров должно быть знакомо и понятно. Про незнакомые читать тут, (необязательно)

Моделька создается в общем так же, как и обычно в сталкере. Шейп для этой модельки необязателен, но если сделаете будет плюсом. Уже существующие в СЗ модели лежат по адресу gamedata\meshes\ui\equip\head

Где это лежит в запакованных ресурсах - не спрашивайте, я не помню) Но если все распаковать, то точно будет.

Когда написали конфиг и сделали модель, надо записать в конфиг координаты аттача шлема на голову ГГ. Как это сделать, читаем здесь.

Также рекомендуется ознакомиться с этим постом.

Изменено 29 Сентября 2023 пользователем Zander_driver

[Zander_driver 10 348]

28.10.2023 в 03:13, ~{MODoGEN}~ сказал:

То что выделил зелёным - эти параметры вообще используются игрой?

Неа. Устаревший рудимент, ни для чего не используемый. Ни на что не влияет, можно и нужно удалить из конфига.

28.10.2023 в 03:13, ~{MODoGEN}~ сказал:

И какие у них взаимоотношения с синими параметрами?

У них - никакие. Синие просто действуют. При надетом глушителе, домножаясь на коэффициенты из конфига глушителя.