Перейти к контенту

Вылеты без логов - в чём причины и как с ними бороться


Рекомендуемые сообщения

Если вы столкунулись с вылетом без лога, постарайтесь вспомнить следующее:
1. Что изменяли в последний раз
2. Во время чего вылет произошёл
3. На какой локации
4. Случайно ли он проявляется или только при приближении к определённому месту/объекту
5. Попробуйте отследить имя последнего перешедшего в онлайн объекта
6. Попробуйте поискать в своих правках ошибки, подходящие под нижеперечисленную классификацию.

Известные причины вылетов без лога:


1. Ошибка в вызове функции из диалога: после имени функции скобки писать не нужно.
При таком написании будет вылет без лога:
<action>file.func()</action>
Пример правильного написания:
<action>file.func</action>
(file - имя файла скрипта, func - имя функции)
Во втором случае вылета не будет даже если функции file.func не существует, НО это справедливо только для тега action.
В теге precondition вызов несуществующей функции
<precondition>file.func</precondition>
приведёт к вылету без лога.

2. Пустые значения в конфигах. Вылет будет, если оставить значение какого-либо параметра, считываемого движком, пустым. Например, если в конфиге оружия оставить строку такого вида:
inv_name =

3. Попытка прописать несуществующие кости модели в некоторых параметрах. Например, в grenade_bone для оружия. Тут, думаю, всё ясно.

4. Попытка прописать спавн несуществующего предмета в профиль NPC (файлы character_desc_*.xml). Вылет без лога будет, если в секции spawn (тег supplies) прописать название несуществующей секции.

5. Не следует вписывать текст диалога напрямую в тело описания диалога. При превышении определённого количества символов будет вылет без лога. Чтобы обойти это ограничение, пишите текст в текстовом строковом файле и используйте ссылку на него.

6. Партиклы. Вылеты могут быть, если задать слишком высокие параметры при редактровании партикла. Также вылет может случиться, если в данный момент отыгрывается слишком много партиклов. Например, такая ситуация может быть, если в онлайне слишком много аномалий и/или артефактов.

7. Нельзя прописывать наличие подствольника оружию, в классе которого он не предусмотрен. Например, для класса CWeaponLR300 (имя скриптового сета - WP_LR300).




1. Неправильный тип данных
Такое случается при попытке чтения (из пакета или ltx-файла) одного типа данных функциями, предназначеными для другого.
Пример: если движок запросил bool-значение (true или false), а вместо него получил nil, число или строку, то игра вылетит с пустым логом.
Также не следует указывать аргументы при вызове движковых функций, не принимающих никаких аргументов.

2. Неправильное использование класса net_packet()
По сути, это частный случай первого пункта.
При сохранении - может возникнуть при попытке сохранить nil-значение с помощью функции для сохранения числа, строки или чего-то ещё.
При загрузке - важно не перепутать написание. В функциях чтения аргументы указывать нельзя.
Пример неправильного написания:

packet:r_stringZ(self.wounded)

Пример правильного написания:

self.wounded = packet:r_stringZ()

3. "Самоудаление" объекта. Тут нужно просто запомнить, что вызывать alife():release(self, true) из методов класса самого объекта нельзя, если эти методы вызываются движком. К примеру, есть у нас сталкер и нам нужно его удалить. И если вызов alife():release(self, true) окажется в любом из методов класса se_stalker, вызываемых симуляцией, то случится вылет без лога. То же самое касается всех остальных объектов, у которых перегружен серверный класс.

Обойти этот баг можно с помощью специальной таблицы объектов "к удалению", удаляемых при каждом обновлении игрока.
В bind_stalker.script пишем следующее:

objs_to_remove = {}
--' Таблица удаляемых объектов
--' Формат: objs_to_remove[se_obj.id] = se_obj

function actor_binder:update(delta)
...
--' Удаление
for id, se_obj in pairs(objs_to_remove) do
    alife():release(se_obj, true)
end
objs_to_remove = {}
...
end


4. Если игра вылетает без лога ещё до главного меню, нужно искать ошибки в скриптах, которые прописаны в параметрах class_registrators, game_type_clsid_factory и ui_type_clsid_factory в конфиге script.ltx. Вылет происходит даже при ошибках синтаксиса в этих скриптах.

5. Неправильные операции с действиями планировщиков (action_planner)
Если при добавлении какого-то действия в планировщик, получаемый методом motivation_action_manager, добавить такое условие

action:add_precondition(world_property, stalker_ids.property_in_anomaly)
то получим вылет с пустым логом. Такая ошибка возникает из-за вложенности планировщиков. "Внутренние" планировщики (в таблице stalker_ids они обозначены как константы с именами, в которых есть слово "planner") для скриптеров доступны только как обычные действия, а не как планировщики, поскольку функции cast_action_to_planner и cast_planner_to_action были вырезаны, хоть и упоминаются в lua_help. Некоторые свойства, номера которых есть в таблице stalker_ids, для скриптов тоже недоступны, поэтому добавлять их в качестве условий тоже нельзя.

 

При создании действий (action_base) нужно прописывать им такие условия, чтобы каждому набору условий соответствовало только одно действие, иначе могут быть вылеты или просто глючное поведение NPC. Еще одной причиной вылета могут быть "тупики" - тот случай, когда есть только одно действие, способное в данный момет изменить какое-то свойство (свойство, которое задается методом add_effect), но его выполнение невозможно из-за заданных условий.

6. Переполнение стека. Чаще всего причина таких вылетов - вызов каких-то функций, которые зависают. После нескольких таких вызовов игра вываливается с ошибкой "C stack overflow", указывающей на произвольный скрипт с любым номером строки, хотя иногда бывают и безлоговые вылеты.  Например, вызов метода actual из планировщика motivation_action_manager может приводить к таким зависаниям, хоть и не при каждом вызове.

7. При попытке использования функций cse_alife_smart_zone.register_npc() и cse_alife_smart_zone.unregister_npc() появляются "плавающие" (через раз) вылеты. В смартах вызовы этих функций вырезаны разработчиками и не используются, но если вдруг вам захочется поэксперементировать с ними, не забывайте о их глючности.

8. Попытка удаления рестриктора, прописанного какому-либо NPC. Этот баг никак не лечится, но его можно обойти. Для этого нужно для каждого живого объекта в скрипт для серверного класса внести специальную таблицу, в которой прописаны соответствия NPC и прописанных им рестрикторов. При удалении рестриктора нужно пробегаться по этой таблице и убирать его из рестрикторов всех NPC, которым он прописан.

9. В некоторых случаях вылет без лога происходит при использовании функции wounded(bool) для клиентских объектов (game_object). Чтобы этого не происходило, не следует вызывать её слишком рано, например, из функции net_spawn(...). Также не следует пытаться менять состояние раненности мёртвым NPC.

10. Вылет без лога случается, если установить состояние тела равным move.crouch и ментальное состояние anim.free. Например, вот такой код

--' npc - game_object
npc:set_mental_state(anim.free)
npc:set_body_state(move.crouch)
вызовет вылет без лога. При установке состояний через state_mgr от оригинальной игры такого вылета не может произойти (установка такой комбинации заблокирована), но если устанавливать состояние напрямую (как показано выше), то вылет будет.

11. Нельзя прописывать недопустимые соответствия серверных и клиентских классов в class_registrator.script. Это может вызвать вылеты без лога, зависания и порчу сохранений. В некоторых случаях могут быть вылеты с логом, в котором упоминаются имена несуществующих секций (в т.ч. содержащие недопустимые символы).

12. Вылет при поытке вызвать level.object_by_id(id), где id > 65535. Подобный вылет возможен и для alife():object(id).

 

 

13. Иногда может происходить вылет "Abnormal program termination" (автосохранение при этом оставалось рабочим), предположительно из-за большого количества NPC. У меня такой вылет происходил  при переходе с Радара на другую локацию, перед этим на Радаре было заспавнено очень много зомби (около 100). По этому вылету пока что могу посоветовать только уменьшение количества респавна.




Конкретные примеры (вырезки кода, вызывающие вылеты) и советы по устранению вылетов приветствуются.

Всем, у кого установлен патч 1.0006, рекомендуется установить фикс. После установки фикса вылеты без лога скорее всего исчезнут.




Просьба не спрашивать о причинах вылета с логом. С такими вопросами - в "ковырялки".
Также здесь не следует писать про про вылеты, вызванные редактированием движка. Для этого есть соответствующая тема.

Изменено пользователем Полтергейст
исправлено и дополнено описание вылетов action_planner
Ссылка на комментарий

Полтергейст

При загрузке - важно не перепутать написание.

packet:w_stringZ(self.wounded) -- записать

self.wounded = packet:r_stringZ(пусто) --считать

И если команда alife:():release(obj, true) окажется в любом из методов класса se_stalker, вызываемых симуляцией, то случится вылет без лога

Что то не очень как то понятно:по моему опыту вылет при удалении\дропе может быть разве что в том случае, если движок "потерял" серверную юзердату удаляемого объекта в момент операции удаления - и то имеет тогда вполне вменяемый лог - что entity not found.

ищите проблемы в class_registrator.script, обычно просто ошибка синтаксиса.

Ну уж туда то зачем лазить? Классов дефолтных и так 'вагон и маленькая тележка' - куда свои то создавать? На моей памяти одному матерому модмейкеру только один раз за все время моддинга понадобилось там зарегить свой класс. Как говорил один известный логик - "не стоит плодить сущности без необходимости".

Неправильные операции с evaluator'ами или действиями

А у меня к таким операциям лог прилагается - видимо эксклюзивно ;)

Изменено пользователем Garry_Galler
Ссылка на комментарий
Что то не очень как то понятно:по моему опыту вылет при удалении\дропе может быть разве что в том случае, если движок "потерял" серверную юзердату удаляемого объекта

Если объект удаляет сам себя (функция удаления вызывается из методов его класса), то вылет будет без лога. Проверено на функциях can_switch_* вчера.

 

А у меня к таким операциям лог прилагается - видимо эксклюзивно

Попробуйте в xr_camper заменить строку

action:add_precondition (world_property(stalker_ids.property_danger,false))

на

action:add_precondition (world_property(stalker_ids.property_danger_grenade,false))

- лога не будет.

 

Ну уж туда то зачем лазить? Классов дефолтных и так 'вагон и маленькая тележка' - куда свои то создавать?

Ну почему, мне как-то раз понадобилось повесить скрипты на гранаты (на их серверные объекты) и тут как раз глюкнул akelpad в момент сохранения - подрезал конец документа и заполнил его 5-ю копиями одной строки. Результат очевиден :)

 

P.S. Битые сохранения и попытки использовать функции класса net_packet(), не соответствующие типу данных (к примеру, packet:r_stringZ() для считывания числа или bool) тоже относятся к первому пункту (неправильное использование класса net_packet())

Изменено пользователем Полтергейст
Ссылка на комментарий

Еще добавлю от себя о вылетах без лога. Хотя наверно это вещь очевидная...

При "как бы некритичных" синтаксических ошибках в скриптах, вызываемых из binder:update (по крайней мере из апдейта актора так) - получается вылет без лога вообще. т.е. В лог-файл ничего не сохраняется.

Речь идет не о ошибках типа "лишняя скобка" или "нехватает слова end", а к примеру, точка вместо двоеточия при вызове методов или неправильные типы данных (у меня например, game_object* попал туда где ожидалась строка, и получился такой вылет)

Мод, где не бывает одинаковых путей - Судьба Зоны. (Лучшее, что у меня получилось на X-Ray) На базе модифицированного движка OGSR Engine.

Бывший мододел на X-Ray / Начинающий игродел на Unreal Engine. Программист.

AMD Ryzen 9 7950X (16 ядер, 32 потока, 5.75 ГГц); RTX 3080; 128 ГБ DDR5; Arctic Liquid Freezer II-420; 3 ТБ SSD PCIe 4.0; 4ТБ HDD.

Ссылка на комментарий

Одной из распространённых причиной вылетов без лога, являются эксперименты с логикой НПС прописываемой в скриптах, гулагах.

Как пример прописывая walker несуществующие ("неуместные", для данного типа :) ) пути:

path_walk = w1 или p1 или walk1 или patrol_path ... (возможно этот путь подойдёт для camper и пр., а не для walker)

path_look = s1 или patrol_path или patrol_path ... (возможно этот путь подойдёт для camper и пр., а не для walker)

Возможно если их зарегистрировать для него, например в gulag_tasks или в своем gulag_new - вылета не будет ;)

 

Ссылка на комментарий

SEA_CAT

Не понял. Если в логике НПС прописать путь которого не существует, то игра или вылетает с движковом логом (у меня такое бывает на ЗП) или вылетает с руганью на _г.скрипт. Да и притом, если я не ошибаюсь пути для валкера и кампера одинаковые.

Freedom

Ссылка на комментарий

_Призрак_

Ну я выше весьма "заинтриговано", всё расписал, а так суть ты уловил верно, если мы прописываем своему вновь созданному НПС существующую! логику от других - найденную в одном из gulag_escape, gulag_agroprom и пр. То если не обращать внимания на его сущность sleeper, camper, walker... а просто прописать её своему к примеру walker-у от какого нибудь camper-а с локации Радар - где у него всего одна точка пути? и он просто физически не сможет перемещаться ко второй несуществующей то следует вылет (и в ТЧ по крайней мере лог пустой!).

 

Дабы избежать такой неприятности, надо в зависимости как спавним если all.spawn - то либо брать из него подходящие пути для своего walker-а или прописывать там свои и после указывать их в своей логике. А если скриптом, то в логике ему указывать один или несколько существующих путей (внимательно посмотрев на тех у кого их позаимствовали).

 

В Зове Припяти я в основном спавнил НПС в сквадах, потом на новых локах начал их расставлять по точкам через all.spawn (логику и маршруты писал сам), потом забросил это дело до лучших времён так как столкнулся с массой ограничений (по сравнению с ТЧ), и с самой главной проблемой под названием - оптимизация, после моих нововведений, (новые группировки, засады, монстры, флора, фауна), FPS даже на мощных видеокартах и "быстрой" памятью падал до критически неприемлемых значений!

 

P.S. Поэтому я поступил иначе, взял интересующие меня модели из ЗП, ЧН и билдов и "слил" на движек ТЧ (получилось даже лучше чем я ожидал), даже старые локации изменились на 50% и более за счёт замены части их содержимого, ну главная идея это сюжетная линия прожженная хардкордом и автотранспорт (включая бронетехнику)!

Изменено пользователем Полтергейст
Ссылка на комментарий
он просто физически не сможет перемещаться ко второй несуществующей

Не понял. Разве если валкеру установить только одну точку пути, то он должен дойти до этой точки, и остановится. Это во всех частях игры так. Не, если ты в алл.спавне сделаешь ссылку на 2 точку пути, а саму 2 точку не создашь то вылет наверняка будет

Freedom

Ссылка на комментарий

Ну я же просто так написал: от какого нибудь camper-а с локации Радар (это снайперы с вышки или возле бункера, а они - camper), и без "пути" точка прибывания у них одна, а если просто взять и прописать её walker-у то ни чего хорошего из этого не получиться (внимательно посмотрев на тех у кого позаимствовали такие path_walk = ... и path_look = ...) - я хотел сказать не 1-я, а изначальная их точка, которая в логике у них прописана так:

[camper]

path_walk = w1

path_look = s1

sniper = true

....

 

т.е. если мы создавая своего walker-а прописали так:

[walker]

path_walk = w1

path_look = s1

....

То получили - без лога ;)

Изменено пользователем SEA_CAT
Ссылка на комментарий

Ребята, вылет будет происходить, если новосозданному НПС присвоить имя пути по которому уже кто-то ходит! А то, какое у них название, где расположена точка - значения не имеет, если это логика в кустом дата, если же в гулаге (esc_gulag), а в логике пути названы walk_man_1, то ОЧЕНЬ важно, чтобы в файлах way_xxx.ltx имена были с приставкой названия гулага esc_gulag_walk_man_1 и все!

Если walkery присвоить точку от campera, то, не зависимо от местоположения этой точки, НПС пойдет и встанет на нее, при условии, что если это точка на другой локации, то между этими локациями должна быть связь граф поинтами, чтобы мобы могли переходить туда-сюда.

Ссылка на комментарий
если новосозданному НПС присвоить имя пути по которому уже кто-то ходит!

Не всегда так. К примеру, в схеме xr_patrol (работы patrol и raid) по одному пути ходят несколько npc. И вылетов от это нет. И вообще, непонятно, зачем для walker делать такой запрет - ну ходят двое по одному пути, ну и что?

Ссылка на комментарий
Ребята, вылет будет происходить, если новосозданному НПС присвоить имя пути по которому уже кто-то ходит! А то, какое у них название, где расположена точка - значения не имеет, если это логика в кустом дата, если же в гулаге (esc_gulag), а в логике пути названы walk_man_1, то ОЧЕНЬ важно, чтобы в файлах way_xxx.ltx имена были с приставкой названия гулага esc_gulag_walk_man_1 и все!

 

Тоже, не совсем соглашусь - так как на практике получал другой результат:

1. Так уж получилось, что своим "спецподразделениям" - охотников за ГГ я присвоил часть существующих путей ближайших к ним гулагов для walker-ов существующие от других walker, а для camper-ов и вовсе с других лок (главное чтобы название их было не "с потолка" взято а из тех, что есть в gulag_tasks например) - а если вписывал своё уже в кустом дата "А то, какое у них название, где расположена точка - значения не имеет" - то получал гарантированный вылет без лога, вот так мне не везло, до тех пор пока названия им не поменял.

 

Ссылка на комментарий
если вписывал своё уже в кустом дата "А то, какое у них название, где расположена точка - значения не имеет" - то получал гарантированный вылет без лога, вот так мне не везло, до тех пор пока названия им не поменял.

Так и не понял, что там с названиями. С чего и на что они менялись? Если оно из gulag_tasks взято, то обязательно надо добавлять к нему имя смарта, иначе вылет будет.

Ссылка на комментарий

Да интересный диалог, чтобы не сбивать с толка - в двух словах (предложениях):

Если использовал существующие пути то вылета не было при условии если не путал пути камперов и валкеров (как не противоречит это сказанному выше).

А если пробовал менять названия путей на свои не упоминания их в gulag_tasks - то вылет без лога был.

 

P.S. - Проверял на практике - сомневаясь в теории.

Изменено пользователем SEA_CAT
Ссылка на комментарий

Похоже это глюки скрипта move_mgr. Вот только не пойму, почему глюки из-за walker, а не camper - там схемы той строк 10. Будем разбираться :)

 

Изменено пользователем Полтергейст
Ссылка на комментарий

Куфзук

Ребята, вылет будет происходить, если новосозданному НПС присвоить имя пути по которому уже кто-то ходит!

 

Вылета не будет если в секции логики Нпс используються полные имена путей из алл спавна (как вы впрочем и сказали).

Или есть работа с сылкой на данную логику в файле загрузки работ (смотрите сидяших у костра в лагере новичков)

 

-- у костра днём

t = { section = "logic@esc_lager_kamp1",

idle = 0,

prior = 6, state = {0},

in_rest = "", out_rest = "esc_lager_guard_kill_zone"

}

table.insert(sj, t)

t = { section = "logic@esc_lager_kamp1",

idle = 0,

prior = 6, state = {0},

in_rest = "", out_rest = "esc_lager_guard_kill_zone"

}

table.insert(sj, t)

t = { section = "logic@esc_lager_kamp1",

idle = 0,

prior = 6, state = {0},

in_rest = "", out_rest = "esc_lager_guard_kill_zone"

}

 

 

 

логика

 

; сидящие днём у костра

[logic@esc_lager_kamp1]

active = kamp1@esc_lager

 

[kamp1@esc_lager]

center_point = camp_center

path_walk = camp_center_task

soundgroup = esc_lager

meet = meet@lager

 

 

для свободного нпс должно быть так

 

[logic@ля_ля_kamp]

active = kamp@ля_ля

 

[kamp@ля_ля]

center_point = esc_lager_camp_center полное название пути

path_walk = esc_lager_camp_center_task полное название пути

soundgroup = esc_lager

meet = meet@lager

 

Полтергейст

walker делать такой запрет - ну ходят двое по одному пути, ну и что?

 

Запрета нет

хоть сколько нпс могут ходить по одному пути (см выше).

 

Ну и до кучи :ny_ph34r_1:

 

Есть вполне легальная возможность вывода нпс из гулага под свою логику.

Для это го нужно создать дополнительную секцию логики не прописанную в файле загрузки работ гулага но находяшиюся в файле логики работ гулага.

 

 

Ссылка на комментарий

У меня вылетела игра и я не понял почему

1. Создавал НПС редактирую алл.спавн

2. Когда начал новую игру

3. На собственной

4. Игра даже не загрузилась и произошел вылет

6. То что я написал в алл.спавне:

[33]

; cse_abstract properties

section_name = stalker

name = Chehov

position = 98.361450195313,2.5525007247925,54.768836975098

direction = 0,0,0

; cse_alife_trader_abstract properties

money = 5000

character_profile = esc_new_npc

; cse_alife_object properties

game_vertex_id = 58353

distance = 0

level_vertex_id = 3

object_flags = 0xffffffbf

custom_data = <<END

[logic]

cfg = scripts\proba.ltx

; cse[smart_terrains]

none = true

END

story_id = 10001

; cse_visual properties

visual_name = actors\soldier\soldier_beret_1

; cse_alife_creature_abstract properties

g_team = 0

g_squad = 1

g_group = 2

health = 1

dynamic_out_restrictions =

dynamic_in_restrictions =

upd:health = 1

upd:timestamp = 0

upd:creature_flags = 0

upd:position = 98.361450195313,2.5525007247925,54.768836975098

upd:o_model = 0

upd:o_torso = 0.0280130300670862,0,0.999607563018799

upd:g_team = 0

upd:g_squad = 1

upd:g_group = 2

; cse_alife_monster_abstract properties

upd:next_game_vertex_id = 58353

upd:prev_game_vertex_id = 58353

upd:distance_from_point = 0

upd:distance_to_point = 0

; cse_alife_human_abstract properties

predicate5 = 1,2,2,1,2

predicate4 = 0,1,1,1

; cse_ph_skeleton properties

upd:start_dialog =

; se_stalker properties

 

Создаю глобальный мод с новыми локациямЭ

Ссылка на комментарий

Я вот ещё заметил. Когда пишешь диалоги и вызываешь функцию:

<action>file.func</action>

Если после func поставить () то будет вылет без лога. Конечно такую ошибку трудно допустить но были случаи (в моём опыте).

Запомнить: Никаких скобок в вызове функции через диалог не ставить!

Ссылка на комментарий

Есть вылеты без лога при попытке движком прочитать в конфиге небходимые данные, но они равны nil. К примеру, в оружии оставим значение inv_name= пустым.

Также есть безлоговые вылеты, если вы напортачили при ковырянии движка.

Изменено пользователем SkyLoader
Ссылка на комментарий

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

Создать аккаунт

Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!

Зарегистрировать новый аккаунт

Войти

Есть аккаунт? Войти.

Войти
  • Недавно просматривали   0 пользователей

    • Ни один зарегистрированный пользователь не просматривает эту страницу.
×
×
  • Создать...