Kirgudu

@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. Вот и думай. Может стоит обложиться выводом в лог во всех ключевых точках и попытаться понять, что конкретно происходит.