Norman Eisenherz

В OGSR есть callback.level_changer_action. В ТЧ надо поймать активное окно через level.main_input_receiver() и проверить наличие одного из уникальных методов класса CUIMessageBoxEx – вот тут недавно было объяснение. Это в теории; на практике имеем следующее: • у такого окна всего два уникальных метода, GetHost() или GetPassword(), и они есть только у окна с конфигом "ввод пароля для сети" – окно "приглашение к переходу" можно поймать только через общие методы класса CUIDialogWnd, например, if wnd:GetHolder() …; • общие методы определяются для любого диалогового окна – надо будет отсечь инфо-поршни всех обычных окон и КПК; • в оригинальном движке нет инфо "ГГ наступил в область перехода" – придется ловить окно через апдейт, и тут тоже сложность: апдейт ГГ ставится на паузу в диалоге перехода – надо запускать проверку "выброс + окно + метод" отдельным потоком через level.add_call(проверка, действие). Еще вариант: при запуске выброса удалить все переходы на активной локации, а после проспавнить их заново и расставить метки. Потребуется список story_id и spawn_id переходов; если первое значение или ссылку на сам объект можно получить перебором obj:clsid() == clsid.level_changer, то второе (номер секции в all.spawn) в оригинале читать нечем – только выписывать вручную.

@bsanek628 В ЗП ввиду спавна тайников россыпью конфиг является текстовым описанием, хотя и не совсем отделен от объектов в игре: с одной стороны, новые предметы не учитываются без правок [all.spawn] и добавления секции [secret] в custom_data каждого объекта; с другой стороны, изменение количества предметов или удаление имеющихся секций конфига в текущей игре все же приводит к пересчету, хотя и по неизвестной логике – 4 предмета, если в конфиге один, два предмета при указании трех и т. п.

Искать упоминания похожих патронов в конфигах со словами trade и treasure (ЗП: secret) в названии. В этом плане игра не отличается от ТЧ: все данные введены вручную, без рандома и часто одинаковыми простынями "не продается / продается по одной цене для всех NPC" – ссылочные секции есть только в настройках лута в [death_generic.ltx] и входящих файлах.

По образу и подобию ТЧ: искать в [config\] и [meshes\] упоминания ammo_12x76_dart, делать так же. Для совместимости с ЗП можно скопировать все файлы и настройки обычной дроби, а после задать buck_shot = 1 (одна пуля) и поправить иконку/текст/текстуру. Это не даст точного понятия, что за что отвечает (надо читать справочник или выяснять методом тыка), но это позволит добавить патроны в игру.

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

1. Стоит уточнять, что это OGSR. 2. Стоит распаковать себе [gamedata\] и найти [scripts\lua_help] class_callback: как минимум, есть событие on_inv_box_item_drop – надо только потестить совместимость с трупами.

@CiberZold Не путать номер в очереди спавна с фиксированным номером. Так и так получается имя, которое читается через name() – не спорю.

Этим и отличаются. К чему был вопрос?

section_name() – аналог section() для оффлайна Просто name() возвращает либо уникальное системное имя, вроде esc_trader, либо имя и номер спавна: wpn_pm21423. Не путать с именами из [all.spawn] – у них обычно есть приставка с названием локации и какой-то фиксированный номер: val_wpn_mp5_0000.

Ищу текстуру сталкерского экзоскелета в варианте "зомби" с пятнами крови на шлеме

1. Total / Free Commander и прочие файловые менеджеры, поиск текста ui_charinfo_left и ui_charinfo_right, ссылка на XML-описание одной из сборных текстур. 2. Разрешение: обычный формат или широкий.

1. Библиотека io – чтение и запись текстовых файлов (есть ЧН/ЗП, про OGSR не знаю). 2. Написать в консоли help, искать примеры по названиям.

Переспавн при взаимодействии. Спальники так сделаны.

@Kirgudu Добавил класс одного из новичков одному из именных в [character_desc_…xml]: на второй позиции не учитывается, на первой занимает единственный профиль класса именного NPC и приводит к вылету. @AndrewMor Просто закомментировал строку <class>trader</class> в [npc_profile.xml] и [character_desc_escape.xml], оставив только прямую привязку к единственному профилю specific_character. @CiberZold Вот это и сделал с Сидором. В тех же старых постах сказано, что профиль можно создавать прямой привязкой <specific_character> или указанием класса для выбора из нескольких индивидуальных профилей. Вопрос с возможностью двойной ссылки на один профиль при разных классах остается.

Это вообще другой эксперимент. Ради интереса отключил класс в базовом и полном профиле Сидора, оставил только ссылку <specific_character> – спавнится успешно. Исходный вопрос: очень давно очень опытный сталкер написал, что две ссылки <class> в профиле учитываются, но тест показывает, что, как и во всех конфигах, читается только первое из двух значений с одним именем. И то ли условия теста неправильные, то ли тот сталкер ошибся.

старый пост Добавил еще один тег <class> в существующий профиль именного NPC, запустил спавн известного отряда новичков с таким классом: • если новый класс на втором месте, отряд спавнится в старом составе, то есть тег не учитывается; • если новый класс на первом месте, игра вылетает с ошибкой "no default specific character set for class" со ссылкой на класс именного NPC, у которого не осталось ни одного профиля, то есть второй тег снова не учитывается. Как должен работать спавн NPC с одним и тем же профилем через разные классы, и работает ли он вообще?

Там именные секции с логикой или ссылки на те же файлы в [config\scripts\]. Общий файл не могу найти…

В спавн-секциях обычных NPC указаны ссылка на секцию [stalker], включая базовую логику. Несмотря на пустой файл, болванчики сразу после "рождения" уверенно идут в сторону свободных лагерей, воюют, чешут в затылке и т. д. Где это все прописано?

Где хранится описание базовой логики NPC? Файл [config\stalker_custom_data.ltx] пуст, не считая комментария с именем этого же файла.

obj:set_condition(num) Возможно, в OGSR есть метод и для оффлайн-объектов.

@Kirgudu Я познал путь GSC: мало прописать новый класс и группу профилей для новых сталкеров – надо еще указать этот класс в [spawn_sections.ltx] со ссылкой… на тот же класс? При этом в логе вылета ссылка на движковую проверку с какими-то векторами – поди пойми, чего игра хочет.

Векторы, окна, 3D-модели и вообще всё, что не является простым классом типа "строка, число, таблица, …"

Как заставить смарт спавнить определенных сталкеров? ЧН, автобусная остановка на Кордоне (esc_smart_terrain_5_10): хочу повысить живучесть новичков, на которых по сюжету нападают вояки, но не знаю, как привязать определенные профили NPC к логике смарта.

Тогда должен быть доступ к свойству actor.max_walk_weight и к свойству max_weight через класс инвентаря (не знаю, как правильно ссылаться – пользователи OGSR подскажут). Если поршней несколько, info_callback как раз подойдет. - дополнение - Вроде оно (get_ аналогично): db.actor:set_actor_max_weight(num) db.actor:set_actor_max_walk_weight(num)

1. [user.ltx] можно править через консольные команды (прямой ввод или обертка get_console), [actor.ltx] – только с правками движка (OGSR, например). 2. Апдейт нужен для постоянных проверок, вроде таймеров или отслеживания ХП – для разовых проверок есть отдельные события. Инфо-поршень можно ловить через info_callback(info_id) по факту получения, либо запускать проверку "уже есть" при входе в диалог, при старте задания и т. д. Какие условия задачи?