stack trace: Scheduler tried to update object esc_factory_bandit5
Причина якобы "некорректное место спана нпс".
Решение якобы "помогает последняя сохранка, или уйти на другую локацию".
Trollz0r
01.07.2018, 01:37
Неужели говноскрипты выжрали всю память для скриптов? Нет, не может быть, херня какая-то
RayTwitty
01.07.2018, 01:44
Цитата(aka_sektor @ 01.07.2018, 00:36)
Причина якобы "некорректное место спана нпс".
Это частный случай.
В логе достаточно прозрачно написано, что не хватило памяти во время апдейта объекта. Возможно в биндер объекта напихали слишком много логики и/или этих объектов очень много.
aka_sektor
01.07.2018, 02:14
Цитата(Пачкулио Пестрини @ 01.07.2018, 01:37)
память для скриптов
Тут следует уточнить, что имеется ввиду.
Есть такой вылет:
Код
Arguments: LUA error: C stack overflow
8 вариант:
Скриптер в описании оставил такое примечание:
Цитата
Иногда та же самая ошибка, т.е. та же самая причина, может приводить к другому вылету - Ran out of memory. Это когда вызываемые функции успевают "сожрать" всю память раньше, чем "сожрут" весь стек.
Мне известно 2 вида вылета по Ran out of memory:
Оба со скриптами не связаны.
Выходит "LUA error: not enough memory" это то что скриптер имел ввиду под "Ran out of memory"? Или это все же относится больше к переполнению стека?
Цитата(RayTwitty @ 01.07.2018, 01:44)
Это частный случай.
А что бы написало в логе для этого частного случая? Пример есть?
Раз уж:
Цитата(RayTwitty @ 01.07.2018, 01:44)
прозрачно написано
Цитата(aka_sektor @ 01.07.2018, 00:36)
Scheduler tried to update object esc_factory_bandit5
Цитата(RayTwitty @ 01.07.2018, 01:44)
во время апдейта объекта
Цитата(RayTwitty @ 01.07.2018, 01:44)
Возможно в биндер объекта напихали
И как такое отлавливать и решать?
abramcumner
01.07.2018, 10:15
Цитата(aka_sektor @ 01.07.2018, 00:36)
Как посмотрел, частый вылет во многих крупных модах. А в чем причина и как решать? Как-то размыто... Думаю опытные модмейкеры в курсе него. В самом то деле, разве он связан с ОЗУ? По-моему из разговора с каким-то скриптером, я слышал про этот вылет, и причина была отнюдь не в ОЗУ.
Этот вылет и должен быть во всех крупных модах из-за фичи луаджита. Луаджит может использовать память только в младших 2гб, а в крупных модах туда складываются крупные текстурки, крупные локации и все остальное такое же крупное. В итоге через какое-то время младшие 2гб оказываются забиты и, хотя памяти еще полно, луаджит выделить для себя память не может.
Ну а все последние сохранки и переходы помогают из-за того, что при старте луаджит успевает отхватить себе память раньше, чем ее захватят текстурки, и какое-то время луаджит еще проработает.
Я сумел придумать только способ, используемый сейчас в х64-движках: выделить для луаджита память заранее. По нынешним меркам ему нужны сущие крохи - порядка сотни мегабайт.
aka_sektor
01.07.2018, 14:57
Цитата(aka_sektor @ 01.07.2018, 02:14)
относится больше к переполнению стека?
Обнаружил вариант со стеком:
Код
Expression : fatal error Function : CScriptEngine::lua_error File : E:\stalker\sources\trunk\xr_3da\xrGame\script_engine.cpp Line : 73 Description : <no expression> Arguments : LUA error: d:\s.t.a.l.k.e.r\gamedata\scripts\state_mgr.script:197: C stack overflow
stack trace: Scheduler tried to update object djoker
Там далее дали такой ответ:
Цитата
Причина: этот вылет обычно возникает когда оружие свежеубитого непися уничтожено или покинуло уровень (провалилось сквозь землю) в тот момент когда его хотел подобрать другой непись или главгерой
Лечение: обычно достаточно просто загрузить последний сейв и вылет пропадает
Также похоже с вылетом сталкивалась команда OGSE:
Код
Expression : fatal error Function : CScriptEngine::lua_error File : E:stalkersourcestrunkxr_3daxrGamescript_engine.cpp Line : 73 Description : Arguments : LUA error: e:\s.t.a.l.k.e.r\gamedata\scripts\rx_wmgr.script:582: C stack overflow
stack trace: Scheduler tried to update object val_sacrifice_guard1
Вот как описали:
Цитата
Крайне редкие. Возникают совершенно произвольно. Могут быть вызваны как превышением нагрузки на движок, так и совершенно произвольными обстоятельствами – например застреванием NPC в стене. Если они вдруг у вас зачастили – рекомендуется снизить множитель респавна и/или увеличить интервал респавна, а так же рекомендуется снизить таймфактор на две-три единицы.
Вообще, похоже, что строчка Scheduler tried to update object не всегда относится к вылетам с LUA error. Встречалась она и с другими, например в ОП-2:
Код
Expression : I != levels().end() Function : GameGraph::CHeader::level File : e:\stalker\sources\trunk\xr_3da\xrgame\game_graph_inline.h Line : 171 Description : there is no specified level in the game graph : 18
stack trace: Scheduler tried to update object rat_strong33844
Описали его так:
Цитата
Этот вылет рандомный. Многочисленные попытки его исправить пока не увенчались успехом) Причина скорее всего в том, что в ОП-2 значительно увеличен спавн по некоторым квестам, и, возможно, где-то движок не успевает это все корректно обработать. Все большие спавны были разнесены во времени, но до конца это проблему не решило) Этот вылет будет с начала прохождения, но ближе к середине станет гораздо реже или даже вообще прекратится) Просто переиграйте - вылет повторяться не должен.
Вообще как-то странно, похоже строка не всегда является причиной вылета, а просто есть. Вот ещё варианты:
Код
Expression : e_entity Function : xrServer::Process_event_reject File : E:\stalker\patch_1_0004\xr_3da\xrGame\xrServer_process_event_reject.cpp Line : 12 Description : entity not found. id_parent=1350 id_entity=1312 frame=11471
stack trace: Scheduler tried to update object lvl_community_respawn_xxxxx (e.g., esc_soldier_respawn_11350)
stack trace: Scheduler tried to update object particle_instance
Код
Expression : assertion failed Function : xrServer::Process_event_reject File : E:\stalker\sources\trunk\xr_3da\xrGame\xrServer_process_event_reject.cpp Line : 12 Description : e_parent && e_entity
stack trace: Scheduler tried to update object bar_dolg_respawn_325353
Код
Expression : vertex || show_restrictions(m_object) Function : CPatrolPathManager::select_point File : E:\stalker\patch_1_0004\xr_3da\xrGame\patrol_path_manager.cpp Line : 155 Description : any vertex in patrol path [sarc_arhara_zombied_zombik5_walk] in inaccessible for object [sarc_stalk_zombied_2]
stack trace: Scheduler tried to update object sarc_stalk_zombied_2
Или строчка в них не просто?
aka_sektor
01.07.2018, 15:04
Цитата(abramcumner @ 01.07.2018, 10:15)
из-за фичи луаджита
Цитата(abramcumner @ 01.07.2018, 10:15)
луаджит выделить для себя память не может
Так вот где собака зарыта!
Цитата(abramcumner @ 01.07.2018, 10:15)
способ, используемый сейчас в х64-движках: выделить для луаджита память заранее
А ведь x64 ТЧ нету. Как с ним быть? p.s. ссылку можно на x64 движки с этой правкой?
На AMK отписали:
Цитата
У такого навскидку - тысяча пятьсот причин))
Желательно вообще применять правленый движок, который не дает вылета(происходит только зависание персонажа) и сообщает при этом хоть какую-то информацию о причинах.
Первым делом проверяй логику перца - правильность перехода из секции в секцию...
Цитата
максимально выносить весь код из апдейтов внутри неписей.
В том числе из *:evaluate(), уменьшая их количество. Ибо накосорезить там - с легкостью необычайной, внятную диагностику прицепить - близко к невозможному.
Trollz0r
01.07.2018, 15:06
aka_sektor, а какой смысл пытаться анализировать ситуацию, не разбираясь в погромировании и отталкиваясь от ложных предположений? Вон тебе Абрам расписал, в чём дело.
atanda
01.07.2018, 15:25
Цитата(aka_sektor @ 01.07.2018, 14:57)
Или строчка в них не просто?
В исходниках не силён, но есть мысли почему возникает эта строка при разных ошибках. Как можно понять движок пытается обновить объект, но в этот момент происходит вылет (совершенно произвольный) и эта строчка оказывается в стектрейсе.
Хотя в таком случае данная строка никак не относится к теме вылета
------------------------------------------------------------------------------------------------------------- abramcumner, не понял, что вы имеете под словами
Цитата(abramcumner @ 01.07.2018, 10:15)
младших
Цитата(abramcumner @ 01.07.2018, 10:15)
крупных
ввиду? И о какой памяти идёт речь, которая выделена под скрипты и всё что к их относится, которая в принципе выделяется на всю игру(~2gb)?
aka_sektor
01.07.2018, 15:28
Цитата(buffy @ 01.07.2018, 15:25)
которая в принципе выделяется на всю игру(~2gb)?
Если так, то там другой вылет:
И решается правленным .exe под 4 Гб.
abramcumner, может ли это решение помочь с LUA error: not enough memory ?
abramcumner
01.07.2018, 15:47
Цитата(aka_sektor @ 01.07.2018, 15:04)
А ведь x64 ТЧ нету. Как с ним быть?
Есть,
Цитата
ссылку можно на x64 движки с этой правкой?
Абсолютно любой публичный х64. Из-за того, что на х64 данные более пухлые, ошибка с памятью в луаджит появляется и на стандартных локациях. Без такой правки скрипты будут вылетать при начале новой игры. В вышеупомянутом ogsr-engine такая правка есть.
Цитата
На AMK отписали
Это относится к "Scheduler tried to update object esc_factory_bandit5" - завис биндер НПЦ - это как раз логика, аи-схемы и прочие скрипты вызываемые из биндера. У тебя же биндер завис потому, что у луа память кончилась.
Цитата(buffy @ 01.07.2018, 15:25)
И о какой памяти идёт речь, которая выделена под скрипты и всё что к их относится, которая в принципе выделяется на всю игру(~2gb)?
Это одно и тоже. У каждого процесса в винде есть своя виртуальная память, которая может тратиться на скрипты, текстуры, модели и прочее и прочее. Луаджит так написан, что может работать работать только с адресами памяти в диапазоне от 0 до 2Гб.
Цитата
И решается правленным .exe под 4 Гб. abramcumner, может ли это решение помочь с LUA error: not enough memory ?
Нет, луаджит так и продолжит работать с младшими 2гб.
aka_sektor
01.07.2018, 16:01
Цитата(abramcumner @ 01.07.2018, 15:36)
ogsr-engine
Как хорошо что есть готовый вариант бинарников и gamedata, вставил и пошел играть: Спасибо.
