Kirgudu

В упомянутой инструкции не хватает одного маленького, но важного пункта. 5. Открываем скрипт по адресу "gamedata\scripts\state_mgr_animation_list.script" на редактирование. Находим анимацию "harmonica" (в оригинале это строки 437-452) и для элемента "into_music" меняем значение "harmonica" на "play_harmonica" (используем ровно то самое имя, которое дали добавленной в script_sound_music_and_stories.ltx секции, содержащей описание звуковых файлов). И всё заработает. Анимация гитары чуть повыше содержит правильное наименование секции звуковых файлов, поэтому с ней всё в порядке. Модераторам: прошу добавить этот пятый пункт в самом конце инструкции. Можно в виде примечания "если у вас есть анимация, но нет звука губной гармошки...".

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

Однозначно порезали, но не в этой части (по крайней мере с GetSelectedItem всё в порядке). Например, в ЧНЕЕ (другие части пока не смотрел) полностью вырезан функционал game_graph(), включая сам метод, возвращающий данный класс. Об этом нынешние разработчики GSC пишут прямо в скриптах, см. комментарии такого вида: "-- mtb-bartlomiej.kunikowski: Get rid of game_graph in Lua". Вместо этого в скриптах можно найти всего одну новую импортированную глобальную функцию: gg_vertex_level_id(gvid), и один новый глобальный метод: gg_accessible(self.disable_graph_point, true). Может быть, есть что-то ещё, но для того, чтобы это найти, нужно копаться в движке. Что это означает? Да ровно то, что моды, работающие с графом, а также универсальные модули, такие как артосовский, идут лесом. По крайней мере пока не будет найдена равнозначная замена утраченным методам или не будут переписаны сами моды.

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

@Miko посмотрю на выходных. Возможно, скрытая ошибка в модуле Артоса или не всегда корректный вызов одного из его методов из модуля спавна. Какая версия Инструмента использована, от какой даты и из какого комплекта? В том модуле lua_helper, который сейчас лежит в составе комплектов Инструмента, в строке 2284 нет цикла 'for'. Очевидно, что используется более старый комплект Инструмента или в отдельные его файлы вносились изменения. Помочь смогу только с последней версией по ссылке из шапки темы, рекомендую скачать и адаптировать себе именно её по инструкции, потом вернуться сюда с ошибкой, если она снова проявится.

position - координаты в виде объекта с типом vector, можно подставить как vector():set(x, y, z), где x, y, я - соотв. координаты по каждой из осей lvid - id level вертекса. Например, для текущего положения героя вычисляется функцией db.actor:level_vertex_id() gvid - id game вертекса. Например, для текущего положения героя вычисляется функцией db.actor:game_vertex_id() Конкретные значения? Откуда я знаю, это уже определять самостоятельно, смотря куда что должно заспавниться. А вообще, об это я и говорю. Всё вышеописанное - такие азы, без изучения и знания которых далеко продвинуться не удастся, а водить за ручку слишком накладно. Крайне рекомендую поизучать скрипты оригинала, тему "справочник по функциям и классам" здесь, на форуме, другие темы, и только после этого приходить с более сложными вопросами.

А вот здесь сложнее, по крайней мере в оригинале. Модифицированные и расширенные движки, возможно, содержат нужный функционал, но это коллегам по цеху виднее, я не в курсе. В оригинале отсутствует коллбэк на взятие предмета из контейнеров, отличных от инвентарных ящиков, в том числе из трупов. Можно завязаться на событие callback.on_item_take, но оно не передаёт сведения об источнике предмета, а значит мы не можем сразу проверить, пуст исходный контейнер или ещё содержит в себе что-то. Получается, что необходимо при открытии любого контейнера (не ящика) предварительно запоминать, какой именно объект открыт. Для трупов монстров это можно сделать, например, в модуле bind_monster.script по событию callback.use_object, для трупов сталкеров аналогичные действия, скорее всего, можно произвести в модуле xr_motivator.script по такому же событию. Что-то такое в голове вырисовывается, хотя не исключаю, что есть способ проще. В любом случае это уже простор для самостоятельных дополнительных изысканий.

@Erty123 один из самых простых скриптовых способов - дописать нужную проверку и действия в функцию actor_binder:info_callback(npc, info_id) модуля bind_stalker.script, например: function actor_binder:info_callback(npc, info_id) -- ...все предыдущие строки... if has_alife_info(info_id) then -- проверяем, что выдана нужная нам инфопорция alife():create("item_section", position, lvid, gvid) end end А вообще способов что-то сделать после получения инфопорции много, как и заспавнить предмет. Рекомендую поизучать уроки и справочники, а также файлы оригинала, чтобы получить какую-то начальную базу.

@ASSASIN64 поскольку файл bind_stalker.script у тебя модифицирован относительно оригинала, очевидно, что правки, предложенные для оригинала, надо применять не в лоб, а учитывая имеющиеся модификации, с умом. В данном случае, если не ошибаюсь, функция должна стать такой: function actor_binder:take_item_from_box(box, item) -- здесь переделываем исходную функцию так, чтобы не выходить из неё, если нет story_id (иначе на "обычных" ящиках не сработает) local story_id = box:story_id() if story_id ~= nil then -- здесь вместо оригинального treasure_manager (вызывает вылет) вставляем строку из модифицированного файла self.am:call( "on_take_from_box", box, item, sim:object( item:id() ) ) end -- проверяем, что контейнер, из которого брали предметы, стал пустым if box:is_inv_box_empty() then -- получаем активное окно и закрываем его local inv = level.main_input_receiver() if inv ~= nil then level.start_stop_menu(inv) end end end

И не сработает так, как ты написал. В оригинальном bind_stalker.script уже есть функция actor_binder:take_item_from_box(box, item) - посмотри внимательно свой же целиком выложенный файл. Ты добавил функцию с тем же названием, но выше оригинальной, второй (оригинальный) экземпляр функции перетирает первый при загрузке, так как стоит позже, и в результате функционал скрипта не меняется. Отсюда вывод: найди в исходном файле функцию с данным именем и отредактируй её так, как показано в примере, только оставь последнюю добавленную строчку (self.am:call(чего-то-там)). Вот тогда всё заработает.

Пример без всяких таймеров (bind_stalker.script): function actor_binder:take_item_from_box(box, item) -- здесь переделываем исходную функцию так, чтобы не выходить из неё, если нет story_id (иначе на "обычных" ящиках не сработает) local story_id = box:story_id() if story_id ~= nil then treasure_manager.take_item_from_box(box, story_id) end -- проверяем, что контейнер, из которого брали предметы, стал пустым if box:is_inv_box_empty() then -- получаем активное окно и закрываем его local inv = level.main_input_receiver() if inv ~= nil then level.start_stop_menu(inv) end end end Нюанс в том, что контейнер закроется не только по кнопке "взять всё", но и если мы вручную переместили из него последний предмет. Доработать под кнопку и/или другие нужды не сложно.

local position, direction, distance = db.actor:position(), db.actor:direction(), 3 local new_position = position:add(direction:normalize():mul(distance)) Вместо db.actor:direction() можно использовать device().cam_dir - тогда будет учитываться не только направление взгляда вправо-влево, но ещё и его наклон.

if self.particle and self.particle:playing() then -- do something end Возможны нюансы в зависимости от того, что в действительности возвращает метод playing(). Там константа на выходе, теоретически 0 или 1, то есть должна сработать как булевый результат, но лучше проверить или посмотреть в движке.

@Norman Eisenherz посмотри свойство self.mgr.synsound в state_mgr_animation.animation:play_rnd(). Это единственное место использования данного свойства и запуска звука после присвоения его в state_mgr.state_manager:set_state(). Если это действительно оно, тогда, возможно, надо будет подумать над передачей в модуль обработки анимации переменной switched как нового свойства менеджера.

@Balavnik этот метод возвращает любой серверный объект, вне зависимости от наличия или отсутствия родителя.

Обновление от 2025-03-01 Исправлена критическая ошибка: при активном показе на худе отладочной информации (по умолчанию клавиша "K") получение любого хита приводило к полному зависанию функционала Инструмента. Такая ошибка наблюдалась на платформе ОП-2.2, однако могла воспроизводиться и на других. Обновлены все конструкторы и готовые комплекты.

Я не большой знаток ЗП, может там и есть специализированные методы работы с поясом. Но в ТЧ и ЧН я действовал бы одним из следующих двух способов (подойдёт и для ЗП, конечно, но может на этой платформе существует более простой подход). Способ простой, но ресурсоёмкий. В модуле bind_artefact в методе artefact_binder:update() проверять, есть ли родитель у клиентского объекта артефакта (функция obj:parent()) и равен ли он id актора. Если да, запускается скрипт, определяющий наличие предметов на поясе с помощью спавна невидимого объекта-разделителя (легко ищется поиском по форуму). Если id одного из предметов совпадает с id артефакта, update которого сейчас работает - прибавляем счётчик времени на поясе и сохраняем значение в свойствах артефакта (net-пакет или pstor объекта). Способ посложнее, но с на порядок меньшей нагрузкой на движок. Когда артефакт может у нас появиться на поясе или быть удалённым из него, точнее, какие сопутствующие события мы можем отследить? Первое, что приходит в голову - это on_item_take и on_item_drop. Второе - это когда предмет уже в инвентаре, но мы перемещаем его между собственно рюкзаком и поясом. Это отследить без модификаций движка сложно, но у нас есть событие закрытия инвентаря, а для надёжности можно добавить проверку и при открытии. Так вот, при этих четырёх событиях мы запускаем функцию проверки предметов на поясе, упомянутую в способе первом, и для всех найденных на нём артефактов активируем счётчик времени, а для тех, что были на поясе ранее, но теперь убраны - деактивируем. Данные об активации счётчика времени и значение самого счётчика можно сохранять в свойствах самих артефактов по факту их перемещения в/из пояса, а прибавлять счётчик - всё в том же методе artefact_binder:update() конкретных артефактов.

@aka_sektor 5-6 тыс. в месяц, вряд ли что-то изменилось. Мур летом подробно описывал в своём объявлении. Многовато, конечно, для регулярных трат не на себя. Надеюсь, месяц-другой мы в этот раз компенсировали совместными усилиями. А на будущее рекомендую таки разместить на постоянной основе объяву с предложением о поддержке сайта. Ничего плохого в этом, как мне кажется, нет.

Обновление Инструмента от 2025-02-08 1. В подразделе Персонажи раздела Объекты добавлена возможность создать раненого НПС. 2. Во всех разделах всем текстовым полям, предполагающим ввод только целых или дробных чисел, добавлен автофильтр, не позволяющий вводить другие символы. Обновлены все конструкторы и готовые комплекты. Хранилище прежнее, ссылка в шапке темы. Приятного использования!

@Balavnik по информации из этого конфига движок создает в памяти свою табличку соответствия числовых значений story_id их строковым синонимам и помещает её в публичный класс story_ids, таким образом ты получаешь возможность использовать в скриптах и конфигах не только числа, но и элементы перечисления, например: alife():story_object(192) равно alife():story_object(story_ids.gar_exit_to_agroprom_01)

@Pavel_2000 в ЧН и ЗП колбэк bind_crow.crow_binder:death_callback вполне себе работает. В ТЧ - наверное, подключать примерно аналогичный биндер.

Налицо ошибка объявления переменной. В таком виде движок ничего не знает о том, что sil_items - это таблица, и считает, что это простая переменная, значение по умолчанию которой - nil. Индексировать действительно нечего. Чтобы исправить ситуацию, достаточно в первой строке написать так: то есть присвоить начальные значения переменным явным образом.

Удивительно, но это уже пятнадцатый новый год, который я буду встречать здесь. Кто бы мог подумать в далёком уже 2011 году, что я смогу и - главное! - захочу провести на форуме столь долгий срок, однако это произошло. Форум, вы, его авторы и случайные читатели, спрашивающие и отвечающие, старожилы и новички, ушедшие, увы, в память и только написавшие первый пост - все за эти годы стали мне вторым домом, уходить надолго из которого не хочется совершенно. Так пусть у каждого из жителей этого дома жизнь в наступающем году будет полная чаша! И пусть новый путь, который с наступлением полуночи у каждого из вас, смею надеяться, начнётся (в чём бы он ни выражался) - пусть этот путь будет добрым! С новым 2025 годом!

Понятно. Это те же яйца, только сбоку. В SRP взяли тот функционал, что я описал выше, и перенесли в настройки группировок. Так действительно удобней, поскольку для небольшого редактирования достаточно изменить только вынесенный в файлы конфиг группировки, а не пересобирать all.spawn, в котором находятся настройки смартов. Но по своему действию и та и эта реализации практически идентичны: оба параметра влияют на построение путей отрядов при войне группировок. Единственное, чтобы заработал вариант SRP, потребуются ещё и сопутствующие изменения в симуляционных скриптах, на ванильном ЧН не взлетит.

@ZeeK точно ничего не перепутал, есть пример? Насколько я помню, в классическом ЧН нет такого параметра у группировок. Есть параметр forbidden_point у смартов, который влияет на построение пути отрядов в войне группировок (да, можно запретить посещение точки отрядами определённой группировки), но это smart_terrain и sim_board.