Prostomod

Да, рестриктор может иметь лишь одну активную схему. Для переключения просто используй on_info, on_timer, on_game_timer, on_actor_inside и т.д. события, через которые можно переключиться на другие схемы. Например: on_game_timer = 30 | {+gen_oso_researches_react_on_guard} sr_idle@psi_blow %=send_message(gen_oso_researches_8)% Где: on_game_timer = 30 - это 30 секунд игрового времени, после которого начнёт выполняться триггер {+gen_oso_researches_react_on_guard} условие, при котором будет выполняться (в данном случае - наличие поршня) sr_idle@psi_blow - имя следующей секции %=send_message(gen_oso_researches_8)% - действия, которые надо выполнить при активации (в данном случае - вызвать функцию) Тут (http://stalkerin.gameru.net/wiki/index.php?title=Настройка_логики._Часть_3) можно подробнее про триггеры прочитать (да и в целом полезно про логику).

Постой, крышка - это партикл или как-то засунутая динамика в аномалию? Что-то я думал всегда, что аномалия с динамикой - это особые сложные системы с рестрикторами или просто что-то жутко заскриптованное. А от какой конкретно секции унаследованно? Ну или на основе чего? Я глянул конфиг жарки - там есть параметр use_secondary_hit = true, ну и параметр secondary_hit_power. Точно не знаю, но мб в нём дело?

А там как реализовано? Аномалия и динамический объект по отдельности? В конфиге аномалий увидел такие параметры: ignore_nonalive = false ignore_small = false ignore_artefacts = true Мб если ignore_nonalive выставить false, то аномалия будет сама на крышку срабатывать...? Ну или я б попробовал развить идею с партиклом и рестриктором: при подходе запускаем партикл и отбрасываем крышку (как - не уверен, мб получиться как с псевдопсом в старом КБО в оригинале). Ну и аномалию поставить внутрь этого набора, которая уже и будет, если что, игрока бить.

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

Ну а какой правильный? Дополнено 16 минуты спустя Хочу извиниться перед всеми за компостирование мозгов. Предложение поставить особую погоду indoor натолкнуло меня на мысль, что именно погода виновата в баге. Дело в том, что я забыл сказать (точнее, думал, что это не важно), что мод делаю на основе GSWR, и очень похоже, что баг связан именно с этой платформой т.к. я установил чистый ЗП и туда добавил эту локу, и там всё заработало нормально. Буду пытаться решить эту проблему дальше как-то. Ещё раз прошу прощения.

Высокие. Компилирую компиляторами от Sky Loader, использую ключи -static, -underground, -skipinvalid и -skipthm.

mirka Замечено на обоих типах, но сейчас разбираюсь с чистой подземкой.

Ок, я разобрался со сглаживанием, но осталась проблема с яркостью материалов. И да, я попробовал на уровне изменить все шейдеры на вертексные (все default заменил на def_vertex), но эффекта это никакого не дало.

londarov Вроде как записи надо сначала подобрать в инвентарь, потом читать.

Policai Про видео и баг с IN default restrictor'ом для смарта я не знаю. (Насчёт первого - это они так часами могут воевать? Мб с иммунитетами что-то.) Но использование IN default restrictor в качестве разделителя АИ сетки (не ограничение области для какого-то смарта) у меня ещё ни разу не баговалось.

Снова глупый вопрос. Мб уже отвечали, но я или плохо искал, или реально пока не отвечали. Есть у меня на уровне баги, при котором 2 смежных полигона в одной плоскости по разному освещаются, причём явно один нормально, другой багнуто. Я в вопроснице спросил, мне сказали что проблема со сглаживанием и даже показали, как их починить. Однако, там показали метод для 3d макса. Если я правильно понял, там к объекту применяется модификатор smooth, назначается автосглаживание и просто экспортируется. Но вопрос в том, как сделать такое в блендере? Я нашёл модификатор smooth в нём (столбец deform), но, в отличии от видео, у меня он превратил модель в кашу из полигонов. Если что, использую 2.93. UPD: в ЛС подсказали. В блендере это sharp edges, и если их убрать - этот баг с тенями пропадает.

Я, если нужно телепортировать кого-то куда-то, просто накидываю затемнение, и потом уже телепортирую. Вроде как раз если НПС их не используют, то всё ок. В оригинале в Припяти по вейпоинтам вертушки летают, и сетки в воздухе нет. Можно поставить рестриктор с типом IN_default_restrictor, тогда НПС не будут ходить по этому участку сетки. Пример есть в той же оригинальной Припяти, где под общагой есть большая АИ сетка, которая соединена с остальным уровнем, но отделена таким рестриктором. Только в компиляторе спавна потом надо отключить separator check, если включена.

Вообще никакой реакции или что-то да показывается? Как запускаешь? Лог есть?

AfterGlow Что-то мне всегда казалось, что аномалии тоже подчиняются онлайну-оффлайну... Ладно, разберусь. А так уже через движок со статичным партиклами вопрос решил. Дополнено 1 минуту спустя В чём может заключаться проблема, что некоторые материалы слишком яркие на уровне? Локация подземная, NoSun коробка тоже присутствует. Догадываюсь, что что-то с материалами связанно, но что конкретно - нет идей. И есть ещё проблема, не знаю причина как у первой или другая. Два смежных полигона, но освещение по разному обрабатывают (один нормально, другой багуется). Материал одинаков, лока та же самая. Тут уже нет никаких идей.

По идее, отключаться должны автоматически или надо скрипт для этого писать? Я попробовал сделать такую аномалию, но в итоге партиклы никуда не подевались. И да: 1) я удалил обычные статические партиклы, которые заменял аномалиями. Потом в самой папке с уровнем заменял level.ps_static. 2) проверял дистанцию a-life. Выставлено 150 метров, но эти аномалии видно и с 400 метров, и даже дальше. Дополнено 7 минуты спустя Особенность работы функции check_npc_name в том, что она ищет в имени НПС строку, которую ты передашь в аргументе, а не сравнивает их. Таким образом, например, если у тебя есть 2 нпс sim_default_military_1 и sim_default_military_1_2, то оба будут проходить по такому условию. Мб у тебя в логике другой работы в смарте опечатка, и там назначены пути/смарткаверы из этой работы. В xr_conditions есть функции is_day (промежуток от 6 утра до 21 вечера) и is_dark_night (от 22 вечера до 3 ночи). Ещё для сюжетных моментов из оригинала есть функции is_jup_a12_mercs_time (с часа ночи до 5 утра), zat_b7_is_night (с 23 до 5) и zat_b7_is_late_attack_time (с 23 до 9). Но если нужен другой промежуток - эти функции просты и однотипны, написать свою не должно быть трудно.

Hunter Хз, вдруг РоХ втихую переквалифицировался в ММО треш мод...

Как по мне, тут есть противоречие: если кто-то не знает, как работает память в коде или указатели/ссылки, то откуда он может знать, что у него происходит в коде? Ок, часть его косяков компилятор оптимизирует, но много чего останется. Допустим, получилось скомпилировать такой код. Хорошо, если это выльется в "относительно безобидную" просадку ФПС (Например, каждый тик пытается передать в функцию массив из условно 1000 элементов какого-то класса в том месте, где правильнее было передать по константной ссылке? И не один раз за тик, а раз 100. Да ещё и возвращать каждый раз такой-же массив.). А ведь это может превратиться и в утечку памяти или неопределённому поведению. Хороший получится мод, который лагает и постоянно вылетает (или вообще не запускается) из-за косяков движковых правок. Хоть за счёт красивого кода мб ему будет легче получить помощь, но такое обучение явно будет не самым комфортным. Если уж и хочется движок править, то, думаю, в большинстве случаев лучше понять, что от него вообще ожидается (=как его API выглядит в скриптах, конфигах и других местах, что означает, что нужно поковырять геймдату и мб что-то реализовать без движка), потом в стерильных условиях (=какой-то мелкий учебный проект на любую идею, какая нравится) отработать навыки в С++, и только потом лезть. Если есть желание - можно и сразу с нулевыми знаниями пытаться его править. А при должном усердии даже сделать что-то рабочее (и даже что-то крутое, если постараться), и даже без каких-то серьёзных косяков. Но в большинстве случаев, как мне кажется, начинать изучать моддинг сталкера с исходников движка со всеми его подробностями, а не его API (конфиги, Lua и остальное) - такая себе идея.

Вот прям так с порога (без осмотра геймдаты, без мелких правок а ля "прописать ствол торгашу в продажу") качал исходники движка и вносил правки? Не, если это реально так, то молодец (без сарказма), я б так если б и смог, то потратил бы слишком много времени. Сам список, как по мне, является стандартным для любого ЯП, на котором собираешься что-то более-менее серьёзное делать (в т.ч. Lua). Но вот для движка по хорошему нужно знать и про работу с памятью (в С++ нет сборщика мусора - легко забить всю память или потерять в производительности, если сделать что-то неправильно), и про указатели (очень опасная вещь, если толком не понимаешь, что делаешь). Да и понимание ООП и всяких алгоритмов и структур данных поможет комфортнее разобраться со всем. И я очень сомневаюсь, что новичок, который решит начать делать мод, с радостью побежит первым делом учить всю эту прелесть, особенно если его цель - сделать сюжетный мод без каких-то особых выкрутасов, или реализовать не особо сложную механику. Можно конечно всё это выучить "в боевых условиях", но тут опять вопрос с том, стоит ли?

Пожалуй соглашусь, что самое базовое понимание работы движка знать полезно. Однако, как по мне, в начале лучше просто абстрактно представлять анатомию движка без подробностей, а не разбираться с плюсовом коде самому. Примерно на уровне как раз тех статей на тему "Как работают игровые движки". Всё-таки С++ далеко не самый простой язык, новичок в лучшем случае ничего не поймёт, а в худшем попытка разобраться в работе движка просматривая код отпугнёт (если только этот "новичок" уже не является С++ программистом). Для новичка пусть все подробности движка остаются внутри т.н. "чёрного ящика", хотя бы на первое время. Лучше пусть будет известно на уровне скриптов lua где и как что срабатывает, на уровне конфигов где и как читается, а так-же где и что надо прописать своё, чтобы оно работало (огромное количество инфы об этом есть в интернете + никто не отменял эксперименты). А "чёрный ящик" (если вообще понадобится) уже открывать тогда, когда есть понимание работы более высокоуровневых процессов - будут известны хоть какие-то отправные точки, через которые можно связать С++ код с конфигами, скриптами и прочими вещами и начать разбираться в движке.

Нафига!? Вот уж точно одно из последних, что б стоило бы изучать тому, кто вообще не разбирается в этом. Как минимум, в плане изучения моддинга сталкера. А вот уже основы Lua - самое то. Конфиги и скрипты надо в первую очередь смотреть. А дальше изучать по обстановке. Ладно, прощаем:). Сообщение выше скорее адресовано ТСу, а не тебе, чтобы он всё-таки не пытался в движок сразу залезть. Там и у опытных далеко не сразу получится разобраться.

Спидран по моддингу: Пытаемся установить правку как есть. Пытаемся запустить мод Если всё работает ок - см. п. 8 Если ошибка - ищем лог и смотрим в нём, в чём причина (как правило, это последние строки лог). Ещё можно сразу после вылета открыть любой текстовый документ и нажать Ctrl + V (когда происходит вылет и есть его лог - игра автоматически записывает его лог в буфер обмена). Гуглим, в о чём лог По рекомендациям из инета вносим нужные правки. Повторяем п. 2 Вуаля! Ты теперь модмейкер, можно выходить на Ap-Pro Showcase с трейлером своего супер-пупер мода (походу, так как раз и рассуждают создатели васянских сборок на СоС'оиды) Если серьёзно, очень и очень неопределённый вопрос. В целом, алгоритм выше рабочий, но для чего-то серьёзного придётся учиться и учиться. Начинать лучше с простого (правки параметров в конфигах, торговли, создание диалога и т.д.). Точкой входа во всё это я б назвал гуглёж "Как <сделать что-то> в сталкер <ТЧ/ЧН/ЗП/...>?" и дальнейшее разбирательство что, зачем и почему.

vladvexa188 Глянь на примере оригинальных Янова и Скадовска. Про мутантов не уверен, но НПС там точно не воюют.

Ник Нуми Зависит от того, что это вообще такое. Если это попытка починить мод - мб стоит спросить разработчика. Если это адаптация чего-то к чему-то, то поищи эту секцию в исходных модах и проверь её наличие в своей адаптации. Дополнено 7 минуты спустя Вопрос к спецам по партиклам (и просто шарящим за оптимизацию). Так получилось, что у меня на уровне должно быть много партиклов. Как я понял, они не подчиняются онлайну-оффлайну и работают всегда (как минимум, я с другого конца карты видел включённые партиклы). Естественно, из-за этого у меня низкий ФПС, если я смотрю в сторону скопления партиклов. Собственно, вопрос: как можно оптимизировать партиклы без вреда для картинки? Т.е. простое "уменьшить их количество" не подойдёт. Мб существует какая-нибудь галочка в настройках партикла, чтобы можно было как-то отключать определённые типы партиклов в зависимости от расстояния до ГГ (имеются в виду партиклы, которые расставляются из вкладки Particle System в СДК, а не те, что включаются через логику или скриптом). И связанный с этим вопрос. Что меньше нагружает систему: куча отдельных партиклов или один большой партикл, при условии, если суммарное количество эмитеров в обоих ситуациях одинаково? Например, 10 партиклов, состоящие из 2 эмитеров, и 1 партикл, состоящий из 20 эмитеров (т.е. 10 отдельных партиклов объединены в 1 большой). И кстати, если кто-то знает движок, в котором поработали над оптимизацией партиклов - сообщите пожалуйста.

Я и не говорил, что это плохо. Хотя, например, затупы НПС в оригинальном моде, как оказалось, вина движка.

Тут имелась в виду адаптация мода на последнюю версию Advanced X-Ray (в оригинальном моде она жутко устаревшая). И автор указал, что отвечает он только за сам мод и не даёт гарантии, что все правки (в т.ч. эта адаптация), сделанные сторонними пользователями, будут нормальными.