Kirgudu

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

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

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

@Pavel_2000 если со всеми проверками "на дурака", то примерно так: function delete_af(actor, npc, p) if type(p) == "table" then -- проверяем, что параметр передан и имеет табличный тип local story_id = p[1] -- присваиваем story_id из параметра if type(story_id) == "string" then -- но если передана строка, то story_id = tonumber(story_id) or story_ids[story_id] -- пробуем превратить строку в число или получить числовой story_id из штатного перечисления по его наименованию end if type(story_id) == "number" and story_id > 0 then -- проверяем, что story_id найден, имеет числовой тип и больше нуля local lc = alife():story_object(story_id) -- ищем объект по story_id if lc ~= nil then -- проверяем, что объект найден alife():release(lc, true) -- производим удаление объекта end end end end Использовать так: %=delete_af(af_mahovik_1)% или так: %=delete_af(111)% Это, разумеется, сильно избыточный вариант, который полностью исключает вылет, если передано что-то не то. Но если уверен в том, что пишешь в логике, скрипт можно и сократить.

Потому что так написан движок. Метод серверного объекта :name() существует, а метод того же объекта :id() - нет, вместо него числовое свойство .id. На это тебе даже лог намекает: И если в данном случае ты напишешь log1(""..wpn.id), то будет тебе счастье.

И если с момента появления предоплаченной игры в доступе прошло не более 14 дней.

В ЧН и ЗП, а также в модифицированных движках или расширителях. В оригинальном ТЧ нет поддержки методов IO.

@monk я в скриптах подсказал и сделал что мог, проверил: story_id назначается как надо, ошибок нет. Однако после присвоения story_id там действительно идёт сбой логики. Вот я и подумал: может, Васяну ты в процессе своих экспериментов что-то в профиле нахимичил, спец. логику, флаги или ещё что-либо, что позволяет ему такое улучшение игнорировать (в хорошем смысле). Я такого не помню, но я-то как раз только в скрипты и лез, оставляя остальное на тебя.

У серверного объекта position является свойством, а не методом (функцией). Выполнение будет приводить к ошибке, как у тебя, тогда как правильное написание будет таким: if zone and zone:inside(obj.position) then

Если только m_timers от того же Артоса на OGSR переделать... Вот только зачем? 5 лет назад уже был предложен простой и действенный способ подменить хранилище se_stor Артоса на вариант из OGSR, при этом не меняя ни строчки кода в использующих хранилище скриптах. Внутри модуля таймеров вызываются глобальные GetVar и SetVar, которые можно подменить ровно таким же способом. @Stalkersof ничего сложного в работе с таблицами в OGSR нет, информации достаточно даже той, что представлена в официальном Wiki. Вот такой код выполнится без ошибок (проверил только что за 5 минут): local xvars = get_stored_vars() xvars.items_podobral = {} xvars.items_podobral[1] = { section = "111", rang = 1 } xvars.items_podobral[2] = { section = "222", rang = 2 } xvars.items_podobral[3] = { section = "333", rang = 3 } Но далее надо помнить, что любые таблицы в хранилище размещаются не как таблицы, а как значения с типом "userdata", даже сразу после первичного присвоения. То есть по сформированной выше таблице, например, не получится итерироваться: for k,v in pairs(xvars.items_podobral) do -- do something end такой код вызовет ошибку вида «"userdata" не является таблицей». Не получится использовать table.insert и table.remove, не выйдет посчитать кол-во элементов #xvars.items_podobral и так далее, то есть совершить любое действие, которое доступно для стандартных таблиц. Чтобы работать с таблицей, записанной в хранилище, необходимо её сначала конвертировать в понятный для lua вид: local t = xvars.items_podobral() -- выполнить одноименный метод -- после выполнения переменная t содержит в себе стандартную таблицу Но вот если требуется переприсвоить какой-то элемент таблицы, это можно сделать посредством прямого доступа, без конвертирования: xvars.items_podobral[2] = "новое строковое значение" В общем, всё необходимое описано на оф. ресурсе. Сверх этого рассказать что-то сложно. Пробуй, экспериментируй.

Поделиться текстом ошибки в голову, видимо, не приходит? Какая ещё, в таком случае, требуется подсказка, если она уже дана?

@Stalkersof вылет может быть и не связан с приведённым кодом, по крайней мере я в нём ошибки не вижу. А пример уже давали ранее, целый набор функций для работы с этим хранилищем:

@Stalkersof можно использовать SCRIPT_VARS_STORAGE

Скорее всего в использованном модуле m_netpk. Предположу, что взята версия от 2017 года, что выкладывалась тут неоднократно, в том числе мной, а эксперименты проводятся на платформе ЧН или ЗП (но не ТЧ). Есть в ней один авторский недосмотр: для класса net_se_actor использован конструктор function net_cse_alife_creature_actor:__init(obj,mode), вероятно взятый копипастом из предыдущего одноимённого класса. Попытка создать экземпляр класса net_se_actor (при чтении нет-пакета актора) очевидным образом должна завершиться ошибкой. Решение простое: классу net_se_actor должен соответствовать конструктор funstion net_se_actor:__init(obj,mode). Нужный код уже давно можно найти в разных модах (не помню, у кого первого заметил соотв. правку), а вот сделать аналогичную замену в теме "Сборочный цех" я почему-то забыл. Исправляюсь. Свежую версию m_netpk можно скачать здесь:

У меня работает: Chrome v130.0.6723.117 64bit.

@imcrazyhoudini скинь, конечно, но я доберусь до проверки не ранее, чем в воскресенье, и не гарантирую, что смогу помочь. Нет, чисто со скриптовой точки зрения я проверю, что, например, story_id присваивается правильно и существует далее. А вот с логикой не особо в ладах, вряд ли получится понять, что там может ломаться. С этим к другим специалистам.

Это же просто строки, если правильно помню. Как они могут давать вылет при определении типа? Но вообще интересный вопрос, надо будет поэкспериментировать как-нибудь.

@imcrazyhoudini всё, я понял, что у тебя за последовательность событий, раньше как-то туманно было. Ты спавнишь отряд, и из этой же логики в следующей секции запускаешь квест, целью которого является искомый story_id. Честно говоря, я не уверен, что между двумя частями логики проходит достаточное для получения сервером информации о story_id количество апдейтов. Если это так, рекомендую попробовать сделать запуск квеста во второй секции логики не на on_info, а, например, на on_timer с таймаутом в пару секунд. Однако если с промежутком между секциями логики всё в порядке, предлагаю посмотреть на содержимое функции task_objects.get_inited_task, где обрабатывается параметр квеста target_story_ids. Первые несколько строчек выглядят так (остальные нам не интересны): local sid = tonumber(self.target_story_ids) -- считываем из параметра квеста story_id if(sid) then self.target = id_by_sid(sid) -- находим серверный объект по story_id и берём у него id (функция в _g.script) if not(self.target) then -- проверяем, что полученный id не пустой abort("Target for storyline task doesnt exist. Story id [%s]", tostring(self.target_story_ids)) end ... Получается, что если бы story_id не был присвоен нашему объекту, мы неминуемо дошли бы до вызова функции abort. Вот и думай. Может стоит обложиться выводом в лог во всех ключевых точках и попытаться понять, что конкретно происходит.

@imcrazyhoudini как связана инициализация квеста с использованием только что присвоенного story_id, непонятно: опять сделано что-то, что осталось за кулисами. Когда будет время (скорее всего, в предстоящие выходные), постараюсь сам воспроизвести ситуацию на файлах чистой игры и предоставлю результат для изучения. А пока дальше сам, мои советы на какое-то время иссякли. Не исключено, что успеешь сам найти решение проблемы раньше, метод-то вполне рабочий - подтверждается реальными опытами в существующем моде.

Можно воспользоваться функциями из _g.script return sobj and zone and (IsStalker(sobj) or IsMonster(sobj)) and zone:inside(sobj:position()) and not sobj:community() == "stalker" а можно пойти с другой стороны и перебрать только те объекты, в свойствах которых есть функция community(): return sobj and zone and sobj.community and sobj:community() ~= "stalker" and zone:inside(sobj:position())

@imcrazyhoudini и не заработает таким образом. Ты пытаешься найти серверный объект по его story_id, но сервер ничего об этом номере не знает, поскольку ты вот только что его присвоил.. Обрати внимание на последний спойлер в моём примере, а именно _g.script и функцию level_object_by_sid, специально модифицированную для таких случаев. Используй её или, если нужен только id, можно вытащить кусочек функционала из функции с поиском в db таблице, куда мы положили нужную информацию при назначении story_id. Либо производи нужные действия не на том апдейте, когда story_id присваивался, а позже. Самодобавленный смарт, значит. Ясно. А то одно из предположений было, что отряд не спавнится из-за указания невалидного смарта.

@imcrazyhoudini, что такое второй параметр yan_ryaboy из твоего вызова спавна отряда? Вот этот: И ещё вопрос: что именно не работает-то? Спавн отряда? Или назначение НПС из этого отряда story_id? Если второе - как проверял?

1. Я функцию create_npc в sim_squad_scripted.script выше сначала показал с ошибкой, затем поправил почти сразу после публикации поста, но в примере выше она осталась с ошибкой. Не исключено, что по каким-то причинам эта ошибка к вылету не ведёт, но при этом и не работать не даёт правильно, такое бывает. Рекомендую снова взять себе эту функцию из моего поста, теперь она там исправлена. 2. Не показано, где и как происходит создание нужного отряда. 3. Не показано, добавлен ли новый story_id в реестр. В остальном модификация оригинальных функций произведена правильно, кроме вышеупомянутой других ошибок не вижу. Опять же, по такой схеме story_id добавляется Васяну и потом используется в моде Final Stroke, там это проверено не раз и успешно работает.

@imcrazyhoudini придется подождать, я за компом буду уже не скоро, в лучшем случае дня через 3. Может кто быстрее подскажет.

Отряду никак, story_id может быть присвоен только объекту, но не группе объектов. Одному НПС из отряда, если этот отряд симуляционный (то есть один из многих отрядов с идентичным профилем, создающийся для целей войны группировок), тоже никак. Симуляционные скрипты не смогут решить самостоятельно НПС из какого отряда должен иметь уникальный story_id. А вот если такой отряд один на всю игру и спавнится по какому-то событию из логики или вручную, тогда есть лазейка. Для этого можно модифицировать следующую цепочку функций (см. места с комментариями, оформленными --<< ... >>): Тогда, например, создание из логики уникального отряда, первому (либо единственному) НПС из состава которого будет присвоен story_id, будет выглядеть так (показано на примере Васяна со Свалки): [sr_idle@story_messenger] on_info = {+gar_story_searched_digger_body} sr_idle@story_messenger_dogs_spawn %=create_squad(gar_digger_messenger_man:gar_smart_terrain_8_5:731)% где 731 - добавленный в том числе в game_story_ids.ltx персональный story_id. Примечание: для модификации net-пакета и присвоения story_id в данном примере использован модуль m_netpk от Артоса: https://www.amk-team.ru/forum/topic/13216-sborochnyj-ceh/?do=findComment&comment=971137