Prostomod

Skala Да, моя вина, в скрипте, который в том посте ошибка. (видимо, никто больше моим методом не пользовался, раз ошибка всплыла лишь спустя год) Пост я исправил, скопируй оттуда по новой функцию send_message_from_id (просто скопируй весь фрагмент, потом всё у себя в messages.script выдели и поверх всего вставь обновлённый код).

Skala Не нужно. Просто создаёшь, вставляешь туда функцию send_message_from_id, а потом копируешь и вставляешь функцию для xr_effects. А потом не забудь поправить в логике вызов =send_message_from_id на =send_message (если все имена сохраняешь как у меня)

Skala Если у тебя всё ещё не работает, можешь тогда прислать, что ты вписал в xr_effects? Просто у меня в моде этот код исправно работает.

Domovoi Суть моего способа в упрощении не самой функции, а её использования. Так, у меня все сообщения удобно расположены в одном конфиге (ну или в отдельной иерархии конфигов, фича с #include "filename.ltx" на месте), а не по всей логике и скриптам в моде, благодаря чему удобно, если что, менять их. Ну и, к тому же, точно не будет проблем с вводом аргументов в функцию, потому что фактически 4 разных заменяются одним. А вообще, каждый сам решит, какой им проще использовать.

Skala А куда ты прописал функцию? Сама она не для xr_effects.script, я предполагал, что она будет в каком-то другом файле, а в xr_effects.script будет другая функция, которая уже и вызовет send_message_from_id. Наверно, стоило это упомянуть тогда. Пример, как у меня это оформлено:

Skala Если мне когда-нибудь пригодится сделать эффект ослепления от ядерного взрыва на X-Ray, то теперь понятно как такое реализовать...

Крим Создаёшь аномальную зону (имеется в виду объект anomal_zone в СДК) с каким-то именем (*), пишешь к нему примерно такой конфиг Потом можешь отключить свой радиационный очаг функцией =anomaly_turn_off(имя твоей аномальной зоны из *) и включить через =anomaly_turn_on(имя твоей аномальной зоны из *). Только один момент: аномальная зона всё-равно включится, если пройдёт выброс. Избежать этого можно поправив скрипты немного.

Вот это вообще то что нужно! Спасибо!

xrEugene Stalkervernite О, да я вижу, что тут двое шарящих за создание локаций. Ничего если я тут задам вопрос, раз так звёзды сложились? Вам приходилось ли самим создавать маску террейна и _det текстуру для травы? Если да, то как вы их создаёте? Вручную в фотошопе рисуете или автоматизируете как-то в 3д редакторах? А то у меня для своего мода (не конкурс) есть один огромный наземный уровень, для которого в условном фотошопе я опупею вручную вырисовывать всё.

Крим Да, я помню тот скриншот из текстового редактора, всем сервером M.F.S. офигевали. И именно тогда у меня зародилась идея приделать логику от НПС и предметов к квестам (кстати, сделать это легче, чем кажется). Ну у меня технически, конечно, всё поделено на фрагменты (как раз эти 3 квеста... если не вру), но юридически (с точки зрения игрока) там был один квест, а тот факт, что этот квест включает в себя и деф со сталкерами, и стелс, и прочие прелести жизни сталкера (и даже немного наркомании) - это лишь "небольшой" нюанс...:) UPD: Наврал я всем, сорян:) У меня технически 4 квеста: 1 короткий, но на весь мод, и 3 больших последовательных, но которые необходимы чтобы пройти мод. Ну и ещё мини квесты по типу "Забрать хабар" или "Поболтать с НПС"

В прошлом году у меня работа по факту как раз из 3 квестов и состояла:)

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

А "неучастникам" отвечать можно? Просто ситуация интересная: если считать только время, когда нормально моддингом увлекаюсь, то 1 год 4 месяца. А если всё время ковыряния (включая время, когда ничего не получалось и я ничего не понимал), то точно более 5 лет. Но при этом ещё был перерыв года 2-3, когда я моддингом не увлекался, но зато учил Unreal Engine и программирование в целом, и потом со всеми этими знаниями вкатился назад.

Имелось в виду не "сделать своё решение", а "автоматизировать запуск этого решения"

Крим И не лень же было вот всё это прописать... Я у себя в моде ради такого переписал механику квестов, чтобы подключить логику (состояния логики как у рестрикторов и дверей) и не конопатить всё в одну строку.

It is a prerendered video made in Blender. In real game such graphics would destroy everyone's computer.

andreyholkin Ядро у всех кастомных движков на ЗП +- одинаково. Поэтому намного проще разобраться в проблеме другого, который делает на, например, iX-Ray, когда ты специализируешься условно на OXR, чем помочь кому-то, делающему мод на ТЧ, когда ты разбираешься только в ЗП.

RicoNRT Короче: Локацию, траву и сетку собираешь для каждого уровня по отдельности, независимо друг от друга. А вот спавн уже вместе: выбираешь локацию (я обычно выбираю ту, на которой находится спавнер ГГ при НИ, но мб можно любую), потом в секции "Дополнительные спавны" накидываешь все остальные локации, которые хочешь использовать, и компилируешь all.spawn.

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

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

Stalkervernite Давай попробую всё по полочкам разложить: Имелось в виду пустая трата времени, связанная с ожиданием, пока движок пересоберётся после правок. Со скриптовым цикл такой: поправил (сек 5), запустил игру (сек 30), потестил (сек 10), подумал (сек 50), поправил (сек 5)... Без скриптового: поправил (сек 5), собрал (минуты 2), запустил игру (сек 30), потестил (сек 10), подумал (сек 50), поправил (сек 5)... Разница большая, особенно если плавить кучу мелких функций. Конечно, можно (и даже нужно) править такие функции по несколько разом, но на протяжении всего цикла разработки ожидание, пока пересоберётся движок, сожрёт кучу времени. Одна не сильно, но таких одноразовых функций как минимум сотни, а то и тысячи. А это уже хорошо так засрёт движок. В идеале, при разработке надо запускать игру с дебаггером через сборку исходников. Таким образом, у меня уже очень давно не было безлоговых вылетов, а вместо этого я получал вполне конкретные сообщения об ошибках. А вылет без лога просто-напросто означает, что в движке возникла ошибка, которая не отлавливается. Такие ошибки видны только через дебаггер. Скриптовые языки внедряют не для программистов (хотя не, для них тоже), а для геймдизайнеров: они получают простой и гибкий интерфейс для реализации конечного геймплея. А в движке обычно размещают общую логику. Дополнено 0 минут спустя Главное, не впадать в крайности: Делать всё через скрипты Делать всё через движок

Skala Собственно, умение шутить - это ещё и умение донести свою шутку с первого раза. Stalkervernite Движку мало интересно, 20 строк или 20000 строк в функции (хотя 20000 всё-таки повлияют, но это нереальное количество строк в функции, если грамотно всё делать). Тут важен факт того, что ради этой функции будет пересобираться весь движок, который уже может содержать в себе несколько сотен тысяч (а то и миллионов) строк кода. Скриптовые языки специально внедряют для того (и не только), чтобы этого избежать, а не для того, чтобы костылить на них функционал. А вообще, в нормальных движках от этих мелких однотипных функций вообще избавляются, вынося такие задачи в конфиги или вообще в таблицы.

Skala Да я в курсе, я просто ради хохмы написал (типа "Сидор похож на Пуджа"). Ладно, учиться шутить мне ещё долго...

Skala Разве? А, действительно, хотя так похож...

xrLil Batya Что-то мне кажется, что хоть это и реально, но такие мелочи намного проще в скриптах сделать, чем каждый раз ради них пересобирать двигло. Это ж не какая-нить сложная инвентарная система или магазинное питание оружия, которые на скриптах делать не стоит.