Kirgudu

Обновление Инструмента от 2025-09-28. Все последние нововведения и доработки, описанные в предыдущих постах, скопированы во все конструкторы и готовые комплекты.

@Pavel_2000 local keys = { [DIK_keys.DIK_W] = true, [DIK_keys.DIK_A] = true, [DIK_keys.DIK_S] = true, [DIK_keys.DIK_D] = true } function actor_binder:key_hold(key) if has_alife_info("item_id_used") then if not has_alife_info("test_work_start") and keys[key] == true then test_script.test_func() end end end

Обновление Инструмента от 2025-08-21. 1. Функционал, описанный в предыдущем посте в пунктах 2 и 3 (новый раздел "Очистка" и доработка раздела "Переход"), полностью перенесён в конструктор для ТЧ, а также в готовые комплекты для ТЧ 1.0006, ТЧ 1.0004 и OGSR x64 v2.1.416 - v3.448+. 2. Произведена небольшая доработка разделов "Очистка" и "Переход" в конструкторе и готовом комплекте для ЧН. На очереди: конструктор для ЗП, готовые комплекты для ЗП, ОП-2.2, Фотографа. Ссылка прежняя, в шапке темы.

@imcrazyhoudini нет, я же написал, что нужен объект. Актор или любой другой, но нужен. Для демонстрации сделал на чистой игре нижеследующие правки. В логике рестриктора mar_space_restrictor_start_sim.ltx (расположен примерно в межкомнатном проёме между Лебедевым и тактиком) добавил функцию запуска звука при появлении в области действия рестриктора, если первая обучающая миссия ещё не пройдена. [logic] active = sr_idle [sr_idle] on_actor_inside = {+mar_intro_go_to_marsh_done} sr_idle@end_section %=start_sim%, sr_idle@sound %=start_sound% ; добавил здесь ; и здесь зациклил обратно через 30 секунд [sr_idle@sound] on_timer = 30000 | sr_idle [sr_idle@end_section] Саму функцию добавил в xr_effects.script function start_sound(actor, obj) -- здесь obj - наш рестриктор "mar_space_restrictor_start_sim" local snd = sound_object("items\\guitar\\guitar_5") -- взял гитару как длительно звучащую, но подойдёт, разумеется, любой существующий звук if snd then snd:play_at_pos(obj, vector():set(-185, 0.5, -301), 1, sound_object.s3d) end end Указанные в функции координаты соответствуют точке около входа к Суслову, немного ближе к забору. Итак, пошёл к тактику, вошёл в зону рестриктора, чтобы активировать звук, при этом поначалу ничего не услышал. Быстро побежал к Суслову, на полпути к указанным координатам гитара стала слышна, а когда дошёл до места, её громкость достигла максимума. Замечу, что гитара стала различима буквально метров за 10 от точки звучания, не раньше. Это работающий пример запуска звука с привязкой к определённому объекту (не актору) и фиксированным на текущем уровне координатам.

nil откуда здесь взялось?

Если в качестве первого аргумента используется db.actor, то вектор во втором аргументе - это не абсолютная позиция, а смещение относительно актора. Получается, ты запускаешь звук очень далеко от своей текущей позиции, он просто не слышен. Более того, звук ещё и будет смещаться синхронно с актором, сохраняя всё ту же относительную позицию. Чтобы запустить звук в конкретной точке, нужно привязать его к любому другому объекту, кроме db.actor, указать абсолютные координаты (это сейчас правильно) и использовать флаг sound_object.s3d.

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

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

В упомянутой инструкции не хватает одного маленького, но важного пункта. 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() конкретных артефактов.