Prosectors Project

[Карлан 1 049]

Prosectors Project

Текущая версия: 1.7 ( ссылки: [mega] [google] [yandex]  | изменения 1.7 )

F.A.Q | Часто задаваемые вопросы

Народное творчество - здесь

Discord

 

Что представляет собой модификация на сегодняшний день?

Это глобальная модификация в которой добавлены новые локации, расширен оригинальный сюжет Теней Чернобыля, а также добавлено множество оригинальных игровых механик.
Из локаций добавлены, заселены и введены в игру: Болота, Темная Лощина, Туманная Чаща, Мертвый Город, Рыжий Лес, Лиманск, Госпиталь и пара подземок. Есть ряд побочных квестов, но основной упор делался на переработку последней трети сюжета. Была проведена объемная работа с контентом, добавлены и улучшены текстуры, модели и партикли. Добавлено множество игровых нововведений, а также доработок для уже существующих.
Традиционно наш ИИ разнообразит геймплей и создаст много интересных игровых ситуаций, а экономика заставит с умом подходить к выбору снаряжения и выстраивания деловых отношений с торговцами и группировками.

 

 

О всех обнаруженных проблемах пишете. От вас требуется: описание бага, алгоритм его воспроизведения (на тексте или видео), сохранение с багом или рядом с ним, лог игровой сессии, в который была проблема, и файл формата .mdmp (создаётся при вылете). Два последних вы можете найти в "папка_игры\userdata\logs". Также прикладывайте свой user.ltx, он находится в "папка_игры\userdata".
Чем больше вы информации предоставите, тем проще разработчикам будет понять и исправить проблему.

 

 

Изменено 30 Октября 2023 пользователем Дядя Вася
добавить информацию

[Карлан 1 049]

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

[User_X.A.R26 261]

@Карлан, код настолько уникальный и ценный, что конечно же его нельзя никому показывать.) Нуок, напишем свой тогда, а тебе удачи, хорошего настроения и здоровья

Изменено 22 Сентября 2016 пользователем User_X.A.R26

[Карлан 1 049]

@User_X.A.R26, мне искренне не ясна причина твоей иронии. Этот вопрос десятки раз пережевывался в ковырялках, у меня этот код занимает одну(!) строку, более того, практически готовый для этого код я взял из какого-то оригинального(!) скрипта. Там надо всего-лишь сложить два вектора, все. Дело не в уникальности и ценности кода, а в том, что можно публиковать, а что нельзя. К тому же выше я указал, что эта тема ковырялкой не является, хотите узнать как что-то сделано - идите к нам, двери открыты всем, сильвупле, я дам все что есть, вообще, мне не жалко, а помогать что-то там выдирать, или разжевывать по десятому кругу как что-то сделать - увольте. У нас и в коллективе политика примерно такая же, у каждого свой участок, и каждый сам разбирается как выполнить поставленную задачу. Даже вот эта пресловутая телепортация корнями вшита в систему событий, и просто так ее не перенести на оригинал, я дам тебе код, далее ты спросишь как его заставить работать так же как у меня, а я уже объяснить не смогу, так как не знаю на чем ты работаешь. Потом просто все может превратится в печальную картину, когда некоторые будут требовать помочь им создать такое или похожее. Я не хочу давать почву для таких требований, это уведет тему от обсуждения проекта в сторону обсуждения реализаций, на мой взгляд это неправильно. Я прошу меня понять.

 

Я не исключаю (а точнее я в этом уверен), что когда-то я и это выложу, но точно не ранее, чем мы напишем вменяемый отладочный GUI, без этого у меня язык не поворачивается назвать те 100 строк кода отладочным инструментом.

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

---

Пару слов перед конечным дропом я бы хотел сказать по поводу корректности и стабильности.

 

Поскольку в шапке темы я указал, что сделали это все очень давно, а я сейчас в две руки занимаюсь доводкой (также подмечу, что я самый безграмотный участник), посему гарантировать хоть какую-либо корректность/стабильность я никак не могу, это будет совершенно неверно. Анонс привез четырех тестеров, каждый в силу своего желания тестирует, итого можно так очень грубо прикинуть некий абсолютный коэффициент, это число разработчиков (3) и число тестеров (4), в силу времени тестирования последних можно смело делить пополам, итого 5. Соответственно пять мы поделим на количество всех игроков, которые когда-либо поиграют в мод, ну возьмем сто, соответственно этот коэффициент получается ничтожно мал, поэтому прежде чем запускать этот мод - напишите завещание, так как если системный блок превратится в выжигатель - я предупреждал. Релиз, безусловно, лавинообразно повысит этот коэффициент, даже если мод будет заваливаться ежеминутно у каждого второго (но лучше, конечно, исчислять временем).

[Graff46 598]

Есть живые? Есть новости?

[Nazgool 250]

Graff46

 

 

я сейчас в две руки занимаюсь доводкой

Живые есть, а новости только "от производителя".

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

Поэтому пока остались только две руки.

[Карлан 1 049]

Немного о повреждениях. Я изменил алгоритмы на какие-то более вменяемые, по материалам вытянул из ЗП, а поскольку ТЧ на это рассчитан не был, то не стоит удивляться насквозь пробиваемой бетонной стене. У сталкеров и монстров написал самые простые формулы, которые граничат с протекшнами, у монстров задействовал крепость шкуры. Формулы писал с опорой на ЗП, отсюда появился обязательный k_ap, а также смертью храбрых пал k_pierce. Создал конфиг damages_prosectors.ltx, вот там все по новому стилю, можете смотреть. Полностью изменены только бандиты, но этом я и зашился, если кто-то перелопатит все модели, то поставим памятник. При жизни. Описывать новые формулы (да и не только формулы там надо описывать) долго и нудно, да и я не уверен, что кто-то займется переделкой, но, если кто захочет заняться - непременно объясню, а пока можно шапку почитать для успокоения.

 
По багфиксу. Увлекся я тут им, и заливал потихоньку все общеизвестные фиксы с поправкой на ветер. Поправка эта проста как грабли, пока я сам не въеду зачем, что и как это фиксит - не добавляю. Влил некоторую часть из amk+nlc+wawka и zenobian, так же от себя еще вагон привез, и наткнулся тут на одного мастодонта багфикса из-за бугра, и так вот, если у меня вагон, то у него тогда целый грузовой состав! Об этом проекте я, разумеется, знал и ранее, но никогда не пробовал его разобрать. Очень качественно, очень круто, респект! Человек реально вносит очень большой вклад, и его постоянно откачиваемый в морге проект обретает все больше крутых вещей, это не может не радовать, бигап!
 
В свежих апдейтах на 1.2 присутствуют только исправления ошибок, а также небольшие дополнения. Поскольку активно правиться логика в all.spawn, то часто требуется новая игра, потихоньку буду этот вопрос решать экспортом, но пока так, как есть. Сейчас акцентирую свое внимание на глубинных столпах вроде se_* скриптов по части логики, например, добавил опцию респавнеру, чтобы его можно было привязывать к конкретному смарту, и он будет спавнить живность именно для этого смарта (это сделано для уникальных, но не событийных, смартов), но там, конечно, пока карнавал в самом разгаре. Работаем.

Потестировал адаптивность к SDK, не без колдовства, но все работает. Заодно пересобрал граф, но сразу работать в SDK нельзя, я не докладываю файлы уровней, поэтому дополнительно еще нужно будет разбить all.spawn, если крайние правки будут в SDK, то может и доложу.
 
Кому понравилась идея проекта и нужны доступы на репозитории - сильвупле, пишите, пообщаемся. В полный открытый доступ я их пока не выкладываю. Это своеобразный способ поддержки проекта. За фиксами и техподдержкой можно обращаться ко мне в скайп, обещаю помочь каждому.
 
Далее я начинаю свое повествование об версии 1.3.

Она уже будет представлять собою действительно мод, но, наверное, уровня, где-то, 2008-2010 годов. Постараемся под завязку напичкать качественным стаффом по идеям тех лет. И, стоит упомянуть, что разработка еще все-таки не началась, и начнется-ли - никто не знает .

Есть несколько тем, о которых я хотел бы рассказать, начну наверное с переходов между уровнями. Называть это новой системой я не берусь, скажем так, немного обновленная старая. Что представляет собою переход в движке - все прекрасно знают, поэтому не буду расписывать эту всем очевидную вещь. У нас, с т.з. игрока, изменится только интерфейс, который на корню устраняет проблему перехода в несколько вершин из одной. С технической стороны это либо будет гибридная реализация (где все данные будут в скриптах), либо полностью движковая (где все данные будут во флажках). Мы разделили одно от другого, и создали отдельные функции переброса между локациями, это повышает модульность (самой системы) и снижает количество объектов. Отсюда следует, что на переход у нас не тратиться ни одного объекта, и в целом такой объект как CLevelChanger исчезает, он в принципе не нужен со всеми его апдейтами на поимку в него входящих. Переход между локациями в любом случае будет состоять из шести точек (плюс три точки на каждую дополнительную вершину), если удастся придумать какие-то вменяемые алгоритмы расчета позиции и направления, то ручной ввод мы сократим до двух точек (плюс одна). Переходы с помощью проводников, скорее всего, не будут требовать вообще никаких точек и создания каких-то объектов, там будет чистая навигация, но о проводниках пока рано. А пока варианты реализации на обкатке.

 

Изменено 9 Октября 2016 пользователем Хемуль36рус

[Карлан 1 049]

 

to adm: ну вот опять, не хотите по хорошему - не будем .

 

 

Все, хватит с меня SDK, квинтэссенцией моих поверхностных ковыряний выступает тестовое подключение уровня, собственно все в порядке, ничего не поломали, оригинальный SDK практически полностью подходит для работы над проектом, собранный all.spawn сейчас представляет готовый продукт под SDK, его надо только разбить, никаких проблем нет, а я то-ли из ума выжил, то-ли скилы растерял, то-ли склероз, а может просто патологическая неприязнь к SDK, но пару дней для "привязать" повозился, даже учитывая эту не иллюзорную взаимную безграничную любовь.

 

Ну и, собственно тест, как-то так 2571 в наших реалиях (маску - да, не закинул, поэтому видим то, что видим) :

[Карлан 1 049]

К коллективу присоединился @Bak (Rulix).
 
 
Где-то в темах по оружию видел, что ругаются на отсутствие анимки спринта с подствольником. Добавил новую анимацию, ключ anim_idle_sprint_gl, принцип работы такой: если эта анимка указана в конфиге этого ствола и к оружию присоединен подствольный гранатомет, то сначала пытается запустить анимку из этого ключа, если ее не находим, то пытаемся запустить обычный anim_idle_sprint, если ничего не находим, то ничего и не запускаем. Это работает только(!) для CWeaponMagazinedWGrenade.
 
Также изменил имена ключей загрузки звуков перехода в зум на такие же как и у бинокля, чтобы никто не запутался (к тому же это позволяет все это из последнего вырезать уже сейчас). В скором времени, возможно, добавлю новый ключ для бинокля, то есть реализую несколько оставшихся строчек в родительских классах, а бинокль из движка уйдет.
 
От родительского репозитория исправлен еще один недочет, когда при перезагрузке пропадал эффект ПНВ (если был включен).
 
Добавлена кастомизация объема тайников, теперь, например в SDK, можно спавнить тайник любого вида, а задать ему объем возможно прописав в кастом дату что-то такое:

[custom_volume]
value = 150

И у этого тайника объем будет 150 литров. Чтения кондлиста нет, так как затрата ресурсов (не на парсинг кондлиста, а на его поддержку) не оправдывает полезность, а писать новую логическую схему для ящиков (тайников) пока опять же некорректно, так как на все значимые операции существуют коллбеки, и надобность в схеме отпадает, к тому же каждый тайник (у нас и в оригинале) сам по себе висит как минимум на ph_idle.
Также я упомяну, что эта опция никак не сохраняется, исходя из этого опция работает как расширение конфига в целях сокращения количества секций до одной (т.е. оригинальной).

[Карлан 1 049]

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

; example:
[custom_volume]
value = {+moon_phase} 200, 100

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

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

Все мы знаем мод "умное" выпадение частей у монстров, авторов много, но алгоритмы примерно одинаковы, количество частей как правило пишется в переменную модуля, далее эта переменная привязывается к айди и пишется в массив, при хите по части мы уменьшаем ее количество, при юзе трупа спавним количество согласно этой переменной (некоторые спавнят при смерти, сути не меняет если подсчет уже начат, если монстра все таки убили, то спавня при смерти мы обходим (не устраняем) эту проблему в этом случае, но напрасно грузим игру создавая объект(ы), а зачем нам это, правда?), и здесь проблема заключается в следующем, допустим мы ее сохраняем не в актора, а в самого монстра (и здесь не важно как), теперь она у нас содержится в неком локальном массиве, либо массиве модуля (это может спасти), либо массиве стоража (пстор например), теперь по выходу в оффлайн без сохранения пстор монстра у нас становится nil, и вот только в этом случае нас спасет собственный буфер модуля, но это не спасет если мы перезагрузимся пока монстр будет в оффлайне (без сохранения этих данных и на сервере), таким образом у нас затрется наш локальный буфер и по выходу монстра в онлайн у нас на месте переменной с высчитанным количеством появится дефолтное значение, иными словами мы зря грузили игру этими всеми вычислениями как и куда попали, в итоге добиться ничего не добились. Именно этим объясняется полное сохранение параллельного хранилища, так как без разницы куда там его пихать, в серверный объект или в актора, тут мы все сохраним в таком несколько отдаленном от объектов виде, но, тем не менее, интерфейс записи используется абсолютно такой же, как будто мы пишем все это в объект.
 
Еще один плюс этого обновления состоит в том, что в некоторых местах переопределенных серверных классов можно подчистить сохранение переменных, которые используются при работе с клиентским классом (или с серверным, но в момент существования данных), записав их сюда же. Собственно ради этого я это и сделал, это даже можно назвать некой эмуляцией данной операции, но с куда более удобным интерфейсом против net_packet.
 
В итоге, основная суть вышесказанного состоит в том, что теперь при записи в пстор объекта его данные никуда не пропадут до удаления серверного объекта из игры. При удалении объекта из игры хранилище (как система) само вычистит все его данные из этого нового под-хранилища. Если не злоупотреблять, то полезность весьма высока, пока мы в игре, то через этот, рубикон что-ли , переносится псторовский инструмент для сохранения данных. В дальнейшем есть планы написать дампы сигнатур всех объектов для сохранения данных используя вот эту новую возможность хранилища, это позволит в некоторых случаях не возится с серверными классами.

[Карлан 1 049]

Бартер в ТЧ.

 

Если хотите поиграть в "найди 10 отличий", то, например, денежное окно можно лицезреть на 0:07, а меновое на 01:57.

 

 

P.S. Новостей много, немного позже о них напишу.

 

[Winsor 177]

Уважаемый Карлан, а пытались Вы разбираться с проваливанием предметов через текстуры (например, со второго этажа на первый)? кто виноват? неправильные материалы, менеджер коллизий, еще кто?

[Карлан 1 049]

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

 

 

[DaaGuda 50]

Уважаемый Карлан, а пытались Вы разбираться с проваливанием предметов через текстуры (например, со второго этажа на первый)? кто виноват? неправильные материалы, менеджер коллизий, еще кто?

Это из-за аи сетки, если в сдк галочку не поставить в нужном месте, то спавн элементы будут падать вниз на сетку где она есть. Но это не относится к объектам из ящиков, и как видно из видео это пофиксили

[Winsor 177]

ак видно из видео это пофиксили

- а как именно пофиксили - не поделитесь информацией? интересует именно предметы из ящиков Спасибо за любую информацию!

p.s. хотя с другой стороны - что там, что там - все это спавниться ("выпадает"). Но все равно буду очень благодарен за информацию!

Изменено 9 Ноября 2016 пользователем Winsor

[DaaGuda 50]

- а как именно пофиксили - не поделитесь информацией?

Я знаю только

 

 

Если не убрать галочку с "Used AI Locations" то предмет просто напросто провалиться "Как говорят "Под текстуры"" и поэтому при спавне предметов на камни и прочие объекты под которыми нет AI-Map нужно убирать эту галочку. Спавн непосредственрно на AI-Map не требует снятия этой галочки, так как ниже падать некуда.

 

 

А за остольным к автору темы

[Expropriator 2 118]

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

 

При желании можно даже на воде удержать предмет, если пошариться в xr материалах в Шейдер Эдиторе.

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

[Winsor 177]

Уважаемый Карлан, так не поделитесь информацией, как Вы у себя смогли решить эту проблему? 

[Bak 754]

@Winsor, Предметы из ящиков спавнятся скриптом, т.ч. ничто не мешает снимать у них соответствующий флаг used_ai_locations через нет-пакет.

local obj = alife():create(section,pos,lv,gv)
local data = xrs_utils.get_item_data(obj)
data.oflags = bit_and(data.oflags,bit_not(128)) -- снять флаг flUsedAI_Locations
xrs_utils.set_item_data(data,obj)

 

 

Изменено 18 Ноября 2016 пользователем Bak

[Panda19 119]

Тишина... Что-то делается?

[Bak 754]

Работа ведётся, хоть и малыми силами - с кадрами туго.

До публикации новостей всё руки не доходят, но скоро думаю таки будут.