Norman Eisenherz

https://drive.google.com/file/d/1Yf1lx0aeC-q86EpvNveWbJqbE0ZT2oLa Если речь об этом, то такой секции логики в оригинале нет. По идее, можно добавить инфо-поршень с любым именем в [config\gameplay\info_portions.xml], выдать его после задания с замерами и проверять в логике Сахарова/Круглова для исключения перехода к "диалогу", но как точно это сделать, не знаю.

Наличие определенных методов в обычных классах можно проверять через if obj.fx and type( obj.fx ) == "function" Существует ли аналогичная проверка для общих функций языка Lua? В частности, в таблице db.storage[id].mob_trader Сидоровича есть несколько значений, которые дают вылет "no such operator defined" при проверке type(v). Значения можно исключить просто по заголовкам (actions, anim_head, anim_global), но хочется более универсального решения.

1. "What a terrible day to have eyes…" "Есть переменная, которая может быть равна 1, 2 или 3. Если переменная равна 1, присвоить ее значение новой переменной и выдать его, аналогично для 2 и 3, аналогично для варианта проверки той же переменной в списке апгрейдов." Голландский штурвал, нет? После проверки "параметр существует" достаточно выполнить действие return system_ini():r_string(item:section(), "nightvision_sect") То же для проверки в апгрейдах. Аналогично с номером эффекта: отсечь последний знак через check_nv_class():sub(-1) и подставить его в level.add_pp_effector("nightvision_номер.ppe", 1, true) вместо трех проверок "если 1, то 1". Примечание: проверка класса ПНВ должна возвращать только строку, в противном случае x:sub(-1) надо указать в полном виде: string.sub(x, -1). 2. При двух вариантах условий достаточно описать первое и сказать else. 2.1. Если флаг указан внутри функции, как в коде выше, он будет каждый раз сбрасываться на false – статик вообще не будет выведен. 2.2. Во избежание путаницы с частями условия лучше переоформить код: local static_on function nvg_rework() if nightvision and nightvision:night_vision_enabled() then if not static_on then static_on = true -- вывести статик end else if static_on then static_on = false -- удалить статик end end end

В ЧН/ЗП переход от диалога к торговле считается окончанием взаимодействия, из-за чего NPC начинают повторять "Уснул, что ли?" и прочие подобные фразы при активном окне торговли. Куда можно прописать правку логики так, чтобы не указывать условие "помолчите, мы еще не закончили" отдельно для каждого NPC в игре?

Действующая защита от огнестрела прописана в [config\creatures\damages.ltx]. По поводу распаковки либо искать db0-плагин для Total Commander, либо идти в гугл: инструментов более чем достаточно и с командной строкой, и с оконным интерфейсом.

Это несколько смартов со сходными именами – зачем ставить все условия через AND?

Простой id не отличается для серверного и клиентского объекта – проблема в чем-то еще. Может, в названиях смартов очепятки? В крайнем случае, можно буквально встать в смарт и проверить if объект_смарта_по_имени:inside( db.actor:position() ).

1. Нужны скобки вокруг проверок имени: объект И (имя ИЛИ имя …) 2. При таком количестве проверок можно переделать код на сверку по списку: local names = { name_1 = true, name_2 = true, … } … if sobj and names[ sobj:section_name() ] then …

На территории фермы в ТД, где предлагают "гаусс за 800", иногда проигрывается звук "новый контакт в КПК", но количество NPC не меняется. В чем причина такого явления?

В оригинале никак: • статик [maingame.xml] "pick_up_item" выводится и заполняется движком (UIPickUpItemIcon) • состояние PickupMode для команды kUSE переключается движком • событие Game().SendPickUpEvent тоже движковое В OGSR есть callback.on_pickup_item_showing.

Я нашел только один вызов, при создании лагеря. Где именно у лагеря выполняется апдейт? В движке упоминаний load_states или loadstates нет – по крайней мере, в [xrGame].

Цепочка вызовов: [xr_gulag.script] gulag:initialize –> gulag_tasks.loadStates –> load_states по каждой отдельной локации. Как выполняется обновление состояния уже созданного лагеря, где Толик пребывает в оффлайне?

Да, это лишнее – апдейт нужен для обновления подсказки.

@Juk_Bers0vik Спавн имеет то же описание в движке и те же конфиги, только вероятность везде указана 0. Для нескольких предметов надо делать обработчик в [bind_monster.script] update.

Поковырял ради интереса… Есть проблема в очепятке cam_dispersion_inc / cam_dispertion_inc и чтении 0 вместо действующего значения, но есть еще большая проблема в штатной формуле "скорострельность ниже = точность ниже" (val = … + 0.02*rpm*…) без учета возможности стрельбы очередями, из-за чего "снайперский" вариант LR-300 оказывается менее точным по сравнению с обычным автоматом. Кто-нибудь знает моды с более подходящей для ТЧ формулой? Как получить границы нормализации значений для расчета точности одной формулой аналогично ЧН/ЗП?

Это запись "простой текст". Без двойных скобок одинарный слэш будет "съеден" при чтении.

self.object – объект (мутант), для которого сработал вызов какого-то события (спавн, удаление, апдейт) self.object:section() – секция мутанта, который обсчитывается в данный момент

Есть анимация fake_death, но не знаю, можно ли ее достать скриптами.

В "Судьбе Зоны" есть доктор с внешностью "уставших сталкеров пристреливают", хотя крови на его халате не особо много: https://drive.google.com/file/d/146aaJjd-PMUBGB6fMgURhMIDWMzVH6L8

Проверять наличие/отсутствие серверного объекта

Избыток ручного ввода. Заголовки секций и перевод названий можно получить из конфигов каждого объекта, а название метки построить по шаблону вроде "section_mapspot" и выбросить всю таблицу weapon_info – вручную останется только создать однотипные описания меток "wpn_name_mapspot" в XML-файле. Вместо перебора можно привязать создание/удаление меток к сбросу/поднятию оружия на стороне ГГ и сбросу из инвентаря NPC в [death_manager.script].

См. условия выдачи заданий в CRandomTask:check_task_props(task_id): активные задания того же типа, отсрочка, наличие целей на сервере. По-хорошему, надо вывести часть таблицы task_info и проверить параметры этих заданий: для выдачи должно быть status=normal и enabled_props = true.

Может, передавать ранг как аргумент, чтобы обойтись одной функцией? Все равно числа вручную вводятся, хотя при равномерном интервале можно обойтись нижней границей. … = {=actor_rank(min_rank)} … function actor_rank(min) local max = min + 300 if min == 900 then max = min *10 -- на всякий случай end local rank = db.actor:character_rank() return (rank >= min and rank < max) end

Не понимаю, зачем упираться в готовые функции и в чем разница между ГГ и NPC при общем методе проверки ранга. [trade_npc.ltx] -- заменить инфо логической функцией sell_condition = {=fx_name} npc_sell_list, … [xr_conditions.script] -- добавить описание function fx_name() return db.actor:character_rank() < 300 end

Если сравнивать с квестами, parse_condition понимает и ссылки на проверочные функции из [xr_conditions.script] – можно попробовать вместо ±инфо условие вида =fx_name с оформлением в указанном скрипте.