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

[Zander_driver 10 331]

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

 

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

 

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

Вкратце, что собой представляет "Судьба Зоны" 0.8, в техническом плане:

Это мод на базе движка OGSR x64 bit. Если быть точным, движок "Судьбы Зоны" отделился от OGSR в феврале 2020 года, и с тех пор развивался независимо и своим путем. К настоящему моменту движок имеет существенное число отличий. С чистым OGSR-движком мод "Судьба Зоны" НЕ совместим. Для совмещения современных наработок OGSR, с современными наработками СЗ, потребуется заняться совмещением исходников C++. На уровне скриптов и конфигов это невозможно.
Кроме того, структура сохранения многих игровых объектов изменена, так что стандартные модули нетпакетов Артоса, здесь работать НЕ будут. Точнее, они будут работать выдавая некорректные данные. В современных скриптах СЗ, модули Артоса не используются, не вызываются, хотя и лежат по старой привычке, в файлах. se_stor заменен на скриптовую обвязку движкового хранилища данных.

 

Ранее, было время, СЗ позиционировалась как "платформа для разработки модов". Время показало, что вот в таком качестве - никому это не потребовалось.

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

С версии 0.8 и далее, СЗ не обещает никому, обратной совместимости с любыми ресурсами оригинального ТЧ. Будь то конфиги, скрипты, модели или что угодно еще. Так, к примеру, для экипировки ГГ в ряде случаев используются модели, которые в чистом ТЧ вызовут вылет просто при попытке их загрузки.

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

Я позитивно смотрю на настройку игры "под себя" всеми желающими, в разумных пределах. И, позитивно смотрю на то, что (может быть) кто-то будет что-то делать на базе СЗ и для СЗ.

Попытки же утаскивания ресурсов из СЗ в другие моды, по указанным выше, причинам, могут столкнуться с трудностями несколько бОльшими, чем ранее. Не потому, что я "закрыл ресурсы" - я их не закрываю. А только лишь потому, что ресурсы СЗ могут быть не такими, какие ожидает стандартный ТЧ-движок.

 

 

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

 

То что сразу бросится в глаза тем кто полезет в файлы кое-чего знакомого нету, и появилось кое-что незнакомое. Итак.

1. Удалена папка config\misc, вообще, без остатка. Потому что не нужна игре папка в которой валяется "все подряд барахло". И не надо ее создавать обратно, она прекрасно заменяется другими папками:

config\inv - все инвентарные объекты

config\ph - все объекты не относящиеся к инвентарным (ящики, аномалии, физ.объекты и т.д.)

config\setg - все файлы различных настроек, не являющиеся конфигом какого-то объета.

2. Папка weapons так же переехала, т.к. все оружие - это инвентарные предметы, то теперь она имеет адрес config\inv\weapons, и кроме того внутри еще делится на папки по категориям оружия и прочих относящихся к оружейной части конфигов.

3. Оружейникам и вообще всем кто собирается заменять/добавлять оружие в СЗ, рекомендую внимательно изучить систему перекрестного наследования параметров конфига оружия. Ряд "типовых наборов" параметров объявляется в файлах описания оружейных типов, в корневой папке weapons, и затем уже конфиг конечного ствола наследуется от списка таких наборов, в сумме дающих ему все те параметры которые у него должны быть. Такая система хоть и может быть непривычна поначалу, очень удобна т.к. намного упрощает вставку/замену оружия, разработку новых образцов, а так же балансировку стволов под свои вкусы и/или автоматом обеспечивает подстройку новых добавляемых стволов под существующий баланс.

4. Папка config\dialogs содержит описания диалогов, строящихся с помощью модуля assembly_dialogs. в ней находится еще папка pda_screens, содержащая описание страниц ПДА. Про ПДА и способы заполнения его информацией, будет отдельная тема. Слишком обширный там материал)

Назначение остальных папок в принципе, понятно из названия.

5. В версии 0.8, временно исключены из игры, все оружейные аддоны. Прицелы, подствольники и т.д., недоступны игровым путем. Их можно конечно заспавнить, и попробовать куда-нибудь надеть, но ничего хорошего из этого, вероятно, не выйдет. В версии 0.8.1 именно направление оружейных аддонов будет разрабатываться активнее. Планируются к реализации некоторые вещи, которых на базе ТЧ еще не делались.

 

 

 

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

 

Именование иконок

Расширенные возможности использования инвентарных предметов

Оружейные классы 0.8.0

Гайд по квестовой системе

Оружие поддерживает новые звуки

Новые параметры инвентарных предметов

Интерфейсы СЗ 0.8 - 0.8.1

Технологические добавки 0.8.1

Аттач фонарика

Доп.функции для скриптовых игровых объектов

Инфа для моделлеров, об инвентаре ГГ.

Онлайн-справочник по конфигам СЗ. В том числе выполняет поиск по скриптам и по коду движка. Там же, можно скачать актуальный lua_help.

Консольная команда attach_adjust_mode - все для настройки оружейных аддонов.

Новые звуки оружия/аддонов в 0.8.2

и мутантов

 

Исходники движка v.0.8.0

 

 

 

 

 

Изменено 9 Сентября пользователем Zander_driver
Ссылка на конфиг-хелпер СЗ изменилась.

[~{MODoGEN}~ 251]

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

Задрал меня кислотный дождь...

 А крутануть до упора в право, ползунок стартовых настроек Интервала кислотных дождей, плохо помогает?
Я пока ещё не начал полноценную игру на новом патче (пока только топчусь в самом начале, увяз в ковырянии/тестировании правок конфигов и озвучек дробовиков).
Вот и думаю, а когда буду уже начинать НИ, выкручивать этот ползунок до упора в право, или хотя бы на 80 поставить(??). 

Изменено 8 Января 2022 пользователем ~{MODoGEN}~

[Seruva 87]

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

[GYN ZAN 586]

@Seruva его надо уменьшать наоборот, чем больше ты его выкрутишь тем дольше будут дожди. А меньшим интервалом дожди будут чаще но в разы короче. И почти не заметны.

Изменено 9 Января 2022 пользователем GYN ZAN

[stalker rocks 70]

Подсобите пожалуйста в создании батника по оптимизации,вот приблизительный набросок с другого мода :
start .\bin_x64\xrEngine.exe -skip_reg -smap256 -noprefetch -noshadows -nolog -nodistort -no_occq -ss_tga

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

Ключ :

-nodistort

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

Источник :

http://stalkerin.gameru.net/wiki/index.php?title=Расширенные_настройки(ч._3)
Вроде бы помогло немного,но внутреннее чутьё мне подсказывает что с движка можно выжать и побольше,помогите пожалуйста,общее дело же ведь делаем, в этоге всем будет полезно и приятно,и сможете играть с аномалиями с множителем хоть в 2,0 ! 

[stalker rocks 70]

Есть одна мысль как играть с минимальным множителем спавна, но монстры за ГГ будут гнатся оч. долго Сделал правку как и в Лост Альфе : Монстры не привязаны к гулагам в х4 множителе. Но я в этом не особо селён,и не стал заморачиватся и просто увеличил радиусы погони в 10 раз,кидать в папку \gamedata\scripts

https://disk.yandex.ua/d/g8a8AT9-_tusmQ

Полезно будет для тех кто любит радиус симуляции жизни 400 метров и выше,теперь вы точно не убежите,правка крайне хардкорная,ставить на свой страх и риск 

 

[Sultan 182]

"Увеличил радиус погони в 10 раз" !! Действительно суровая правка! Скоро дойдём до того (такого ещё нет ни у кого) что "муты" будут за тобой на другую локу  перебегать! Или на этой локе отстанут а на другой будут встречать их собратья мутанты (сомутыльники).

[stalker rocks 70]

 Побегал,потестил,один кабан гнался за мной так,что забежал аж в подъезд Андрея,затем долго в панике бегал по всей базе,гонятся приблизительно как и в Мизери,а так же дальше тебя видят,следовательно и начинают погоню раньше.
Обновил и улучшил правку,теперь монстры действительно гонятся так,как я и хотел,то есть далеко и долго:
https://disk.yandex.ua/d/tWKmKAOuxEtTqg
 

Изменено 19 Января 2022 пользователем stalker rocks

[mind_al 231]

@stalker rocks то есть, теперь как химеры гонятся)

[~{MODoGEN}~ 251]

27 минут назад, stalker rocks сказал:

Есть одна мысль как играть с минимальным множителем спавна, но монстры за ГГ будут гнаться очень долго. Сделал правку как в Лост Альфе : Монстры не привязаны к гулагам в х4 множителе. Но я в этом не особо селён,и не стал заморачиватся и просто увеличил радиусы погони в 10 раз,кидать в папку \gamedata\scripts

Полезно будет для тех кто любит радиус симуляции жизни 400 метров и выше,теперь вы точно не убежите,правка крайне хардкорная,ставить на свой страх и риск 

 Побегал,потестил,один кабан гнался за мной так,что забежал аж в подъезд Андрея,затем долго в панике бегал по всей базе,гонятся приблизительно как и в Мизери,а так же дальше тебя видят,следовательно и начинают погоню раньше.
Обновил и улучшил правку,теперь монстры действительно гонятся так,как я и хотел,то есть далеко и долго:
https://disk.yandex.ua/d/tWKmKAOuxEtTqg

 Ну ты даёшь! Да ты у нас полон сюрпризов! Такого я от тебя не ожидал! Что ж ты раньше молчал что можешь такое делать?! 
 Так это ж как раз по моей любимой лютой-жесть-хардкорно-обезбашенной теме!  Моя будем посмотреть и заценить! 
Ща мы их... 

[Zander_driver 10 331]

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

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

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

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

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

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

[~{MODoGEN}~ 251]

@Zander_driver , ну я простоя попробую, гляну что там по факту будет. А там видно будет, будет ли так как ты предположил, или как-то по другому.
Надо потестить. А удалить файлики со скриптами этого дела, я всегда успею. Вылетов же не будет, если я их потом удалю и продолжу играть без них? Просто скрипт-система перезагрузится и выкинет инфу о них? 

 Наковыряли мы тут с Серёгой чуток отсебятинку разную, пару вещей добавили торговцу(ам)  
1) Добавлен Геркулес - слишком дешёвый, цену надо повысить, но не знаем где и как. Ключ от этого ларчика с секретными тайнами у Zander-а. 

2) Добавлен 6-ти зарядный помповик Remington-870 .410 калибра. Как это можно видеть, у торговца Любомира, находится в ценовой категории(77 рубликов), где-то между дедовским ружьём и Сайгой-410к. На этой локации продаётся только у этого торговца. Хотелис, понимашъ, оформить его только в ассортимент Крахобору, но ключи от тайных знаний о торговцах, опять же у Zander-а  . Мыс не знаемс как его туда закинуть. Получилось только наипростейшей правкой, путём тыка-эксперимента, закинуть только Любомиру.

 

Изменено 19 Января 2022 пользователем ~{MODoGEN}~

[Alex TOPMAN 306]

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

перекос баланса, где закрученные гайки соседствуют с скучной и легкой игрой на опустевшей локации

А как же проверка на число текущих гулагов на локации и если оно <N, то в течение времени от X до Y спавнится новый отряд монстров в рандомном гулаге локации?

[Zander_driver 10 331]

Технические новинки 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, и т.д.)
Если есть, то при использовании таких боеприпасов звук выстрела будет изменяться.

[~{MODoGEN}~ 251]

Сидим с Сидорычем в его торговом бункере, пьём чай и ковыряемся в поломанном приёмнике, ругаем Zander-а за то что он сломал приёмник, все провода повыдёргивал, гнездо для батареек тоже пораскурочено, hzпойми-как его чинить, концов не можем найти, глухомань-скукатища страшная, утомило слушать треск повреждённой проводки и элект с поверхности... Эх музыку бы починить-включить, я заготовил отличнейший душевный сборничек избранного, старался, собирал, искал, отбирал сидел неделю, 400 композиций перебрал, отобрал 17, а послушать в приёмнике нету возможности, эээх, обидно то как, прям очень-очень обидно и досадно   , ну не в Бар же нам переться что бы там музыку послушать, порадоваться... ээх, печалька...   Что делать? Починить бы, а, @Zander_driver , пожалуйста.  Как, где концы искать? В каком скриптовом файлике с аудиоданными поковырять? И в каком блоке\строчках работать-исправлять-активировать-раскомментировать-разблокировать что надо, что бы потом добавить туда мой заготовленный Сборник? 

Изменено 10 Февраля 2022 пользователем ~{MODoGEN}~

[Zander_driver 10 331]

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

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

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

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

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

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

 

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

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

[Zander_driver 10 331]

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

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

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

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

ссылка.

[Zander_driver 10 331]

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

Часть 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 331]

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

Часть 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 331]

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

Часть 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

[Dikkens 40]

А по боевке можно небольшую шпаргалку?Как она работает в отличие от ТЧ и других модов.