Norman Eisenherz

Остановка выдачи заданий категории recover_item (поиск уникальных предметов) после перехода на новую локацию – проблема древняя, однако найти исправление отдельно от глобальных модов и с описанием не удалось. Выкладываю здесь, может кому пригодится… Проблема кроется в механизме обработки заданий: сначала они все сохраняются в список [task_manager.script] self.inited_tasks в статусе normal (готово к выдаче), потом переводятся в статус selected / completed (начато / выполнено) и удаляются по мере выполнения, при этом задание, которое было только просмотрено (даже в виде заголовка), но не начато, остается в списке навечно. Ввиду того, что все задания recover_item используют общий заголовок, задание со старой локации занимает собой единственное место в очереди, но не выдается, так как не может пройти проверку actor_on_level(…). Дополнительная сложность: перед выдачей в диалог все задания также сохраняются в память отряда под номером категории (для recover_item это номер [3], который почему-то не совпадает с номером [7] в менеджере заданий), а все дефолтные проверки сделаны без учета варианта "есть порядковый номер задания entity_id в памяти отряда squad.random_tasks[?], но нет самого задания в inited_tasks". Правка сводится к удалению "висящих" заданий из памяти и изменению проверок, связанных с перебором squad.random_tasks целиком или только категории recover_item. Ну и, раз уж есть очистка памяти, можно сделать случайный выбор задания при входе в диалог, чтобы не все отряды NPC на локации искали один и тот же предмет. Начинать новую игру не требуется.

Привязаться к таблице в менеджере заданий: local tm = task_manager.get_random_task() local task = tm.task_info[type_parent] if task.status = "selected" then …

Стоит заглянуть в [xr_effects.script] – все подобные переключатели там.

В своем, в чужом, в трупе, в коробке, в границах онлайна или нет? Если у себя, то obj:condition(), где obj – ссылка на объект через секцию db.actor:object(sect) или перебором от 0 до db.actor:object_count() -1.

Не соглашусь: задание "find_item" имеет дополнительную обработку "есть на сервере, но не в кармане заказчика" – надо копировать или "artefact", или "monster_part".

Проверил в ТЧ, подтверждаю (стоило сразу так сделать вместо советов "может быть"). Полный список правок, если кому-то интересно: • [game_tasks_by_vendor.xml] – новый тип задания "parent_new_type" • [task_manager.ltx] – конфиг нового задания, обязательно с заголовком в начале файла • [task_manager.script] – копия строк с обработкой задания "artefact" => "new_type"

Вспомнил вот… Для заданий artefact и monster_part список target_objects не заполняется и метка не создается, а возможность выдачи определяется только простыми проверками "наличие выданных заданий такого типа + отсрочка". Для нового задания с поиском обычной брони (без секции в all.spawn) должно хватить копии конфигов и скриптов задания artefact / monster_part под другим именем.

[task_manager.script] register_target() выбирает подходящие объекты при движковой регистрации и добавляет их id в task_info[задача].task_objects – куда-то сюда надо копать

Остается только добавить такой же флаг в какую-нибудь проверку использования оптики

Что понимается под "поведением" статика? Что-то сложнее "скрыть/показать"?

Перебрать сервер с проверками "существующий объект + наличие родителя + id родителя = id коробки".

@Капрал Хикс Может, это подойдет:

1. Мудреный вариант: взять список [system.ltx] [info_portions] files и перебрать все указанные файлы как текст через getFS():r_open(путь):r_stringZ() с проверкой "есть/нет" по каждому info_id. 2. Ленивый вариант: добавить вывод всех инфо-поршней в консоль в actor_binder:info_callback() и "слушать" с начала новой игры. 3. Неясный вариант: в ЧН вскоре после загрузки в консоль высыпается этот самый список – можно там посмотреть, но вроде как это движковый вызов. Единственное, что можно понять из самого списка – у инфо-поршней есть фиксированные id: [0]=[global_dialogs] … [1350]=[info_up_ac_spas12].

Возможно, нарушен порядок чтения/записи нетпакета ГГ. См. любые недавние изменения со ссылкой на pstor или actor_binder:save() и …load(). Может, таймеры неудачно добавлены?

Да. Минимальные требования: • ссылка в [game_tasks_by_vendor.xml] под каждого заказчика (можно только заголовок task_id=type_parent, остальное скриптом, но потребуется новая игра) • значение text ~= nil (описание/метка), иначе будет вылет при создании диалога • значение target и новая проверка в check_task_props() (при старых проверках часто требуется значение определенного типа или хотя бы ~= nil)