S.T.A.L.K.E.R. Inside Wiki - Вклад участника [ru]

Подключение локаций к моду

2012-07-16T07:54:44Z

Kamikazze: Новая страница: «Category:SDK = Предварительная настройка конфигов = Самое главное - правильно настроенные кон...»

[[Category:SDK]]

= Предварительная настройка конфигов =
Самое главное - правильно настроенные конфиги ЗАРАНЕЕ, маппером при сборке локации. Что нужно сделать с конфигами:

''game_graphs.ltx'' - добавить в конец секции ''[location_0]'' новую локацию, аналогично тем что там уже прописаны. У меня получилось вот так:

<code>[location_0]
000 = "..."
001 = "эскейп"
002 = "свалка"
003 = "агропром"
004 = "агропром-подземка"
005 = "темная долина"
006 = "лаборатория X-18"
008 = "Бар"
009 = "Росток"
010 = "Янтарь"
011 = "лаборатория X-16"
012 = "Милитари"
013 = "Мертвый город"
014 = "Радар"
015 = "Радар бункер"
016 = "Припять"
017 = "станция АЭС"
018 = "ЧАЭС-2"
019 = "бункер выжигателя"
021 = "даркскейп"</code>

Главное - чтобы локация '''НЕ ВКЛИНИЛАСЬ''' в сетку, надо ей дать новый id - тут у нас он 21. Запомним его, он должен совпадать во всех конфигах.

''game_levels.ltx'' - добавить в конец секции ''[levels]'', и создать новую подсекцию локации с тем же именем. У меня получилась level21. Создаём для неё в конце конфига пропись:

<code lua>[level21]
name = k01_darkscape_ogse -- имя локации - задаётся по имени папки
caption = "k01_darkscape_ogse" -- имя на карте, можно потом в строки добавить для подстановки
offset = 3000.0, 1000.0, 0.0 -- смещение (на глобальной картие видимо)
id = 21 -- новый id, должен быть равен указанному в game_graphs.ltx, и быть самым большим, иначе локация вклинится в середину геймграфа</code>

''game_maps_single.ltx'' - дописать в конец ''[level_maps_single]'' текстовое имя локации - ''k01_darkscape_ogse'', затем создать новую подсекцию локации - ''[k01_darkscape_ogse]''. Заполнить параметры:

<code lua>[k01_darkscape_ogse]
texture = map\map_darkscape
bound_rect = -702.00,-704.090, 708.500,716.7780
global_rect = 701.0, 2072.0, 1020.0,2393.0 ;касается только карты в КПК
;1 значение - ширина текстуры (чем значение больше, тем карта уже. правый край неподвижен)
;2 значение - длина текстуры (чем значение больше, тем карта короче. нижний край неподвижен)
;3 значение - ширина текстуры (чем значение больше, тем карта шире. левый край неподвижен)
;4 значение - длина текстуры (чем значение больше, тем карта длиннее. верхний край неподвижен)
weathers = default
;music_tracks = l04_darkvalley_musics</code>

= Компиляция локации =
Если раньше геометрию уже компилировали, можно сделать на драфте, потом обсчитать только сетку, затем забросить её файлы *.ai, *.gct в папку уже готовой карты).
Убедитесь что на локации '''НЕТ''' точки спавна актора (она должна быть только одна на игру), а так же что локация равномерно покрыта графпоинтами. Кроме того
можете сразу сделать графпоинты переходов, чтобы потом не выделять под это один из свободных графпоинтов.

Как положено прогоняем все батники aiwrapper - строим сетку, левелграф, геймграф, аллспавн.

= Сведение единого спавна и графа =

Нам понадобятся файлы:

*Старый геймграф мода
*Геймграф сформированный при компиляции локации
*Старый аллспавн мода
*Аллспавн сформированный при компиляции локации
*Файлы level.ai и level.gct ВСЕХ локаций, которые уже есть в моде - если новых нету то все оригинала
*Папка с полностью готовой локацией
*Утилиты ACDC, gg_cdc_x, game.graph_recompiler

Сначала надо выяснить, правильно ли у нас по геймвертексам села локация. Для этого кидаем геймграф сформированный при компиляции локации в папку с ACDC и прогоняем команду

''ggtool.pl game.graph''

Утилита подумает немного и выдаст вам табличку всех переходов и геймвертексов локаций. Нас интересует список вертексов:

<code perl>l01_escape => 0
l02_garbage => 252
l03_agroprom => 416
l03u_agr_underground => 703
l04_darkvalley => 811
l04u_labx18 => 1109
l05_bar => 1168
l06_rostok => 1308
l08_yantar => 1438
l08u_brainlab => 1529
l07_military => 1545
l10_radar => 1862
l11_pripyat => 2117
l12_stancia => 2273
l12u_sarcofag => 2402
l12u_control_monolith => 2467
l12_stancia_2 => 2517
l10u_bunker => 2661
k01_darkscape_ogse => 2792</code>

Обратите внимание - новая локация должна быть САМОЙ последней, и за ней не должно больше идти никаких локаций. Запишите себе её стартовый вертекс - в данном случае 2792. Если локация вклинилась в середину списка значит вы ей дали не самый последний Id - это не годится, так как переколбасит весь игровой граф, спавн и вы вручную замордуетесь это сводить. Поэтому возвращаемся к шагу 1. Если же локация как положено в конце, всё отлично, можно работать дальше.

Теперь надо поправить АСДС - открываем acdc.pl, находим по тексту "constant levels_inf" структуру с разбиением локаций по геймграфам. Убеждаемся что границы локаций совпадают с теми что у нас получились при проверке графа, удаляем оттуда лишние и вписываем в самый верх нашу локацию. Получится примерно вот так:

<code perl>use constant levels_info => (
{ gvid0 =>3700, },
{ gvid0 => 2792, name => 'k01_darkscape_ogse' },
{ gvid0 => 2661, name => 'l10u_bunker' },
{ gvid0 => 2517, name => 'l12_stancia_2' },
{ gvid0 => 2467, name => 'l12u_control_monolith' },
{ gvid0 => 2402, name => 'l12u_sarcofag' },
{ gvid0 => 2273, name => 'l12_stancia' },
{ gvid0 => 2117, name => 'l11_pripyat' },
{ gvid0 => 1862, name => 'l10_radar' },
{ gvid0 => 1545, name => 'l07_military' },
{ gvid0 => 1529, name => 'l08u_brainlab' },
{ gvid0 => 1438, name => 'l08_yantar' },
{ gvid0 => 1308, name => 'l06_rostok' },
{ gvid0 => 1168, name => 'l05_bar' },
{ gvid0 => 1109, name => 'l04u_labx18' },
{ gvid0 => 811, name => 'l04_darkvalley' },
{ gvid0 => 703, name => 'l03u_agr_underground' },
{ gvid0 => 416, name => 'l03_agroprom' },
{ gvid0 => 252, name => 'l02_garbage' },
{ gvid0 => 0, name => 'l01_escape' },</code>

Сохраняем ''acdc.pl'', она нам чуть позже понадобится для спавна. Теперь надо свести единый граф с нашей новой локацией. Для этого берём ''game.graph_recompiler''. Копируем в его папку в папку ''levels'' целиком нашу папку с новой локацией, а так же создаём папки всех локаций что уже есть в игре, и копируем туда файлы ''level.ai'' и ''level.gct'' ВСЕХ локаций, которые уже есть. В корень копируем старый граф мода, и туда же рядом - новый граф, переименовав его в ''game2.graph''
Теперь правим батник для подключения локации - в нём надо указать какие локации брать из первого графа, и какие из второго, а так же типы графов. У меня получился вот такой батник:

<code bash>ggrc.pl -g1 game.graph,soc -l1 l01_escape,l02_garbage,l03_agroprom,l03u_agr_underground,l04_darkvalley,l04u_labx18,l05_bar,l06_rostok,l08_yantar,l08u_brainlab,l07_military,l10_radar,l11_pripyat,l12_stancia,l12u_sarcofag,l12u_control_monolith,l12_stancia_2,l10u_bunker -g2 game2.graph,soc -l2 k01_darkscape_ogse
pause</code>

Запускаем, ждём пока обработается. Если всё прокатило, тогда мы получим новый файл ''game.graph.new'' - в который вписана локация. Нужно тут же его утащить и распаковать с помощью ''gg_cdc_x'' - проверить ''game.graph.info.cross_edges.ltx'' - все ли переходы остались на месте (должны быть все), а так же как вписалась локация - в ''game.graph.levels.ltx'' наша локация должна быть конечной и с самым большим ''level_id''. В ''game.graph.levels_info.ltx'' она тоже должна быть последней, там же можно увидеть её минимальный и максимальный вертексы. Минимальный вертекс должен быть тот же что был когда проверяли граф, сделанный компилятором - у нас это был вертекс 2792.

Теперь необходимо проверить, не сдвинулись ли идентификаторы локаций в графе. Почти наверняка - сдвинулись, так как в оригинале там есть груда ссылок на тестовые локации разработчиков. Проверить это можно в ''game.graph.levels.ltx'', сравнив идентификаторы локаций там с идентификаторами в конфигах ''game_graphs.ltx'' и ''game_levels.ltx'' - если они отличаются, то обязательно поправляем идентификаторы в конфигах на те, что в геймграфе!

По добавлению переходов - чтобы их добавить вам желательно было заранее создать кроссграфы на локации. Если вы это сделали, тогда вам нужно сделать вот что - распаковать геймграф, сформированный при компиляции локации. Найти там в конфиге графов новой локации - ''game.graph.edges.<id_вашей_локации>'' сделанные вами переходы - они будут помечены как ''"crosslevel edge"''. Ещё их легко найти по параметру ''target_level_id'' - он у них отличается от исходного для этой локации. После того как нашли - скопируйте их прописи в отдельный файл. Затем откройте конфиг новой локации в сведённом вместе графе. При сведении переходы прибились, поэтому надо теперь в новом конфиге найти те же самые графпоинты на которых висели переходы. Ищите их по параметру ''parent_level_vertex_id''. Как только найдете - перед тем как править - скопируйте в отдельный файл. Затем замените им параметры ''target_level_id'', ''target_level_vertex_id'' и ''game_vertex_id'' на те, которые были у сделанных вами переходов. Не забудьте выставить дистанцию - это будет расстояние перехода. Сохранитесь. Теперь откройте конфиги ''game.graph.edges.<id_вашей_локации>'' тех локаций на которые создали переходы - нужно же сделать ещё переходы в обратную сторону. Открыв, найдите там те графы, с которыми только что сделали соединения с новой локации. Ищите по параметру ''parent_level_vertex_id'' - у наиболее подходящего графпоинта он будет равен ''target_level_vertex_id'' перехода с новой локации. После того как нашли, откройте файл в который сохранили не изменённые ещё графпоинты новой локации, на которые были сделаны переходы. Теперь аналогично - затем замените им параметры ''target_level_id'', ''target_level_vertex_id'' и ''game_vertex_id'' на те, которые были у графпоинтов новой локации до изменения. Так мы добьемся того, чтобы входы и выходы с локации были примерно на одном месте. Не забудьте выставить дистанцию! Теперь всё сохраняем, и компилируем граф. Если всё сделано правильно граф сохранится, и при проверке его ''ggtool.pl'' вы увидите в списке сделанные вами переходы.

Если всё нормально, то можно скопировать граф обратно. Теперь важно - нужно так же не забыть скопировать в итоговый пакет файлы, которые при слиянии были поправлены в папке нашей локации. Это:

level.gct
level.graph
level.ai

А так же проверить - были ли внесены изменения в файлы ''level.ai'' и ''level.gct'' уже существующих локаций. Если да, то изменённые файлы тоже надо будет скопировать в итоговый пакет. Теперь займёмся спавном. Берём наш поправленный АСДС и распаковываем спавн, полученный при компиляции локации. Забираем оттуда конфиг нашей новой локации. Затем распаковываем аллспавн мода и кидаем в его папку конфиг нашей новой локации. Прописываем его в ''all.ltx'' аллспавна мода, и увеличиваем в ''all.ltx'' индекс локаций ''level_count'' на единицу. Больше в ''all.ltx'' ничего не трогаем. Далее проверяем число объектов в нашем спавне, и перенумеровываем объекты в конфиге нашей новой локации так, чтобы они были добавлены в конец нумерации. Проверяем прописанные в конфиге нашей новой локации геймвертексы объектов - они должны лежать в пределах вертексов, которые мы получили при проверке геймграфа в файле ''game.graph.levels_info.ltx''

Если всё получилось, то добавляем в аллспавн точки переходов для ГГ и запаковываем спавн обратно. Он готов к работе, можно его скопировать в итоговый пакет.

= Cобираем общий пакет обновления =

В пакет у нас попадут:

*Конфиги

game_graphs.ltx
game_levels.ltx
game_maps_single.ltx

*Папка с самой локацией, при этом в ней должны быть обновлены файлы

level.gct
level.graph
level.ai

- теми, которые получили при слиянии графа

*Изменённые при слиянии графа файлы level.ai и level.gct уже существующих локаций (если локация добавлена нормально, то изменённых может и не быть вообще)

*Слитый game.graph

*Слитый all.spawn

*Необходимые для локации шейдеры

*Необходимые для локации текстуры

= Если нам нужно заменить только геометрию локации не трогая сетку =

Тогда надо заменить в папке локации только вот эти файлы:

*level
*level.cform
*build_details.dds
*level_lods.dds
*level_lods_nm.dds
*level.details
*level.game
*level.geom
*level.geomx
*build.prj
*level.wallmarks

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 11:46, 16 июля 2012 (UTC)

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

Как писать скрипты, не приводящие к вылетам и бою сейвов (часть 2)

2011-03-31T17:52:17Z

Kamikazze: Причина зависаний алайфа из-за ошибок в конфиге торговли

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Как безопасно использовать коллбэки и таймерные события =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Использование защищённого кода в LUA =

Периодически случаются такие ситуации, когда мы можем получить вылет при проверке аргумента, и не можем его адекватно заизолировать с помощью предварительной проверки на валидность значения. Вот простой пример: когда я отлаживал '''death_callback''' неписей, я периодически сталкивался с тем, что обращение к методу '''smart_terrain_id()''' при смерти непися иногда вызывало вылет

<code>smart_terrain:1143 "attempt to index a nil value"</code>

- хотя это свойство является родным методом объекта, и отсутствовать напрочь никак не может. В итоге я пришёл к выводу, что его просто иногда не успевает отработать движок, так как вылет этот проявлялся в основном в интенсивных боях и совершенно произвольно.

Вот код, в котором происходил вылет:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- вылет происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id)
end
end
end</code>

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

'''pcall (f, arg1, ···)'''

<blockquote>Вызывает функцию f с указанными через запятую аргументами в защищённом режиме. Это означает, что любая ошибка, даже критическая, внутри вызванной функции, не передаётся наружу - вызывавшей подсистеме. Вместо этого '''pcall''' перехватывает ошибку и возвращает код статуса. Первая возвращаемая переменная это сам код, (true или false) и если всё прошло хорошо, он равен true. В этом случае '''pcall''' сразу после статуса возвращает все результаты от работы защищённой им функции. Если же в защищённой функции произошла ошибка, то '''pcall''' вернёт false и затем сообщение об ошибке. (Обратите внимание, обработка ошибки присходит БЕЗ вылета! Вместо вылета вы получите вполне адекватную строку с ошибкой, которую можно вывести в лог для последующей обработки)</blockquote>

Я настоятельно советую пользоваться этой функцией в случаях, когда из коллбэков вызываются сложные комплексные обработки, вроде обработки из менеджера вооружений AI-пака. Это позволяет предотвратить как вылеты, так и зависания обработок, и в итоге позволяет хорошо стабилизировать игру.

Возвращаясь к нашим смарттеррейнам... вот как в итоге я подавил вылет типа smart_terrain:1143 с помощью pcall:

<code lua>--- эта функция пытается проверить св-во smart_terrain_id объекта. Именно её мы вызовем в защищённом режиме.
function prot_smt_td(obj)
if IsStalker(obj) or IsMonster(obj) then
return obj:smart_terrain_id()
else
return 65535
end
end

function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if obj then
local strn_id = 65535 --- предварительно проинитим переменную, на
--- случай если у нас prot_smt_td выдаст ошибку
local result, smt_id = pcall(prot_smt_td,obj) --- вызываем prot_smt_td в защищённом режиме
--- и сразу присваиваем его вывод переменным
if result then --- если pcall выдало true
strn_id = smt_id --- тогда применяем полученное значение
end
--- если же обработка выдаст ошибку, то strn_id останется неизменным...
if strn_id ~= 65535 then
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end</code>

В других местах это делается совершенно аналогично. Подробнее об этой и многих других функция для контроля кода, незаслуженно игнорируемых большинством моддеров, можно почитать тут: http://lua-users.org/wiki/FinalizedExceptions - на английском правда, но захотите - разберётесь, там всё просто.

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

= Скрытые критические проблемы в обработке вылетов игрой =

Ведя на днях отладку, выяснил в чём проблема с периодическим боем сейвов и многими другими заморочками как в оригинале игры, так и во многих модах... дело, как выяснилось, далеко не всегда в кривых руках. Есть такая стандартная ф-ция '''abort''' - предназначенная для выкидывания из игры, если что-то пошло не так. И как оказалось, она срабатывает далеко не всегда. Выяснилось это следующим образом:

В одном из логов нашего бета-тестера я увидел '''стандартное сообщение о вылете внутри рабочего лога'''... да-да, то самое которое '''FATAL ERROR''' и дальше по тексту. При этом игра у него НЕ вылетала, это сообщение об ошибке мы обнаружили позже, по случайности. Я заподозрил, что что-то не в порядке, и вставил внутрь этой ф-ции контрольную метку, кидавшую в консоль сообщение, в котором содержался паттерн сообщения об ошибке и само сообщение. Так вот, оказалось, что эта самая функция '''abort''' вызывается в игре с завидным постоянством (вы удивитесь насколько часто), когда возникают исключения в схемах логики, звука и т.д., но игра от этого вылетает на рабочий стол '''максимум только 3 раза из 10 вызовов'''. Вылет НЕ происходит обычно, когда функции передан паттерн ошибки, а остальные параметры пустые, такое бывает, и частенько. И если не сделать внутри этой функции особой метки для вывода в лог, как сделал это я, её вызовы проходят совершенно незаметно, и '''игра после критических ошибок продолжается как ни в чём ни бывало.''' А приводит это вот к чему... Внутри '''xr_logic''' в процедуре записи пстора (хранилища логики и флагов) неписей есть вызовы этого самого аборта в случае если на запись в пстор передана некорректная величина. Ну а так как аборт периодически вообще не срабатывает, то часто попадается ситуация, что неписям в пстор пишется полный ахтунг: куски кода из ОЗУ, всякая муть из лтх-ов, куски аллспавна, всё что угодно. Происходит это оттого, что кодер, писавший эту функцию ('''xr_logic.pstor_store(obj, varname, val)'''), явно и думать не думал что '''abort''' может не сработать. У него запись в пстор стояла после проверки, а не внутри неё (very bad idea), и если abort не срабатывал, игра писала в пстор мусор совершенно спокойно и незаметно для игрока. Потом вся эта хрень попадала прямо в сейвы. Вот проблемный код для наглядности:

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv) --- вот тут мы должны если что вылететь
end
db.storage[npc_id].pstor[varname] = val -- а если не вылетели, всё, получим запись в пстор левой мути
end</code>

Разумеется игра этим пстором в итоге давится, и сейвы сделанные после такой милой записи практически лопаются. Результат - "битые" (на самом деле подлежат реанимации) сейвы. Происходит это потому, что игра из сейва грузит неписям псторы сплошным чтением по словам, пока они не закончатся. В случае же если в псторе обнаруживается записанный ранее мусор, то обработка либо вылетает сразу, либо наглухо виснет, пытаясь запихать эдак с миллион слов в пстор особо отличившегося непися. Как вам например непись с размером пстора в 1697451 слова? В результате попытки его обработать игра просто на стадии синхронизации выжрала всю доступную ОЗУ и повисла.

Решение этой проблемы оказалось достатоно простым: во-первых я предположил максимальный размер полезной части пстора неписей в 20 слов r_u32() (пока ориентировочно, я ещё уточняю эту величину), и соответственно сделал остановку цикла загрузки пстора для неписей через 20 итераций. Там же, где в цикле стояла проверка на валидность записываемых данных (кстати тоже с вылетом в случае провала проверки), я сделал так, что если параметр не относится к валидному типу данных, то запись параметра в пстор не производится совсем. Это необходимо для того, чтобы если вдруг в сейве обнаружится мусор, то он был бы просто отброшен обработкой. Практика показала, что в итоге такие неписи вполне адекватны и в дальнейшем никаких проблем не вызывают, так как начало их пстора, с нормальными данными, обычно не повреждается - мусор дописывается после них, а не вместо них.

Ну и во-вторых модифицировал запись параметров в пстор, просто убрав запись под основание if-else так, чтобы если параметр неверен, он не записывался совсем. Теперь кстати, очень интересно, сохранились ли те же заморочки с ф-цией '''abort''' в Чистом Небе, и если да, то останутся ли в Зове Припяти?

------------

== Необходимые для стабилизации игры правки в модулях ==

'''Эта правка предотвращает запись в пстор если не сработал аборт:'''

''xr_logic.script''

'''Было:'''

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv)
end
db.storage[npc_id].pstor[varname] = val
end</code>

'''Стало:'''

<code lua>function pstor_store(obj, varname, val)
if not obj then return end
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
dgblog("xr_logic: pstor_store: not registered type encountered - write in pstor_store cancelled")
-- abort убран, так как один хрен не работает. Пусть тогда хотя бы в лог что-то валится.
else
db.storage[npc_id].pstor[varname] = val
-- вот так и только так. Если значение не валидно, ничего не происходит.
end
end</code>

'''А эта правка выкинет из пстора весь мусор при загрузке сейва, если он как-то в него попал'''

'''Было:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
abort("xr_logic: pstor_load_all: not registered type N %d encountered", tn)
end
printf("_bp: pstor_load_all: loaded [%s]='%s'", varname, utils.to_str(pstor[varname]))
end
end</code>

'''Стало:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
if tonumber(ctr) > 20 and tostring(obj:name()) ~= "single_player" and npc_id ~= db.actor:id() then
-- максимум 20 итераций - это число ещё уточняется, возможно понадобится больше
-- если у вас в пстор что-то свое пишется, ориентируйтесь на свои значения
-- и обязательно убираем из проверки актора - у него очень толстый пстор, и к тому же
-- если уж поврежденным будет его пстор, то тут точно уже ничего не поможет
dgblog("ОБНАРУЖЕН ОБЪЕКТ С ПОВРЕЖДЕННЫМ PSTOR: "..tostring(obj:name())..
" БУДЕТ ПРОИЗВЕДЕНА ПОПЫТКА ВОССТАНОВЛЕНИЯ")
ctr = 20
end
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
-- не надо пытаться вылетать - просто не пишем поврежденные данные
-- при этом обязательно удалять саму переменную - в результате записи
-- мусора в пстор одно только ее название может повесить загрузку
pstor[varname] = nil
end
end
end</code>

Эти примеры приведены для чистой игры. Единственное в чем не уверен пока, это в том, что максимум полезного размера - 20 слов. Возможно нужно выделить больше, это надо будет проверить ещё экспериментальным путем...

Кроме этого, советую ещё внутрь ф-ции abort вставить отладочные метки, чтобы точно знать когда она вызывалась. Настоятельно советую сделать это даже если вы матёрый моддер со стажем - гарантирую, будете неприятно удивлены.

Я это сделал вот так:

''_g.script''

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
end</code>

По поводу частичной неработоспособности ф-ции '''abort''' я беседовал с Колмогором, и он пришёл к выводу, что видимо вылет игры должен был бы производиться при обработке функции '''printf("%s")''' - ей тут передаётся заведомо отсутствующий оператор и она по уму должна бы сразу крашить игру. Однако в релизе функция printf фактически не работает(она реализована в _g.script через вырезанную функцию log). В результате игра не крашится. Но что поделать, в итоге мне пришлось модифицировать его таким образом, чтобы вылет при его срабатывании был гарантирован:

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
local crash
local ooops = 1/crash
end</code>

Вылет происходит при попытке произвести арифметическую операцию с неинициализированной переменной crash.

== Лечение зависаний алайфа при смерти персонажей ==

Недавно, отлаживая проблемы с зависанием алайфа, мне удалось найти причину этого периодически во всех модах всплывающего сбоя, приводящего к порче сейвов и сильно мешающего нормально играть. Сбой этот возникает при смерти некоторых NPC, обычно квестовых. В частности в моём случае изолировать и отладить это зависание удалось на Юрике, новичке со Свалке, учавствующем в сцене с гоп-стопом. Причина оказалась в обработке посмертной отрегистрации NPC из гулагов, причём сбой там был настоящей матрёшкой, составной из нескольких частей. Правок в итоге было совсем немного, но чтобы сделать их мне пришлось несколько часов распутывать клубок из кросс-вызовов между скриптами smart_terrain и xr_gulag. Итак, начнём с самого начала. Работая над OGSE 069 и 0691 я периодически сталкивался с зависаниями и вылетами в посмертных обработках неписей. Один из таких вылетов - всем хорошо знакомый вылет:

<code>smart_terrain:1143 "attempt to index a nil value"</code>

Происходящий в функции '''smart_terrain.on_death( obj_id )''' - я тогда его заблокировал вызовом его внутри безопасного кода функцией '''pcall''', однако, как теперь выяснилось, этого оказалось недостаточно - баг тут состоит из нескольких частей, и этот вылет указывает только на одну из них. Вот исходный код:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- первый вылет/зависнаие алайфа происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id) -- а вот в этой обработке происходит зависание алайфа. Она очень комплексная, и её сложно распутывать.
end
end
end</code>

Во-первых выяснилось, что изредка вызов '''obj:smart_terrain_id()''' вызывает зависание алайфа даже когда он производится изнутри защищённого кода. Тогда я решил избавиться от использования этой функции в данном месте совсем. После нескольких экспериментов выяснилось, что самым простым, быстрым и вылетобезопасным способом будет считать нетпакет существа в таблицу и выудить идентификатор смарттеррейна из неё. Для этого можно написать свою обработку, однако я, как весьма ленивый программист, не склонен изобретать велосипеды, поэтому я воспользовался уже проверенной у нас и активно используемой в OGSE библиотекой функций для работы с нетпакетами '''m_net_utils''' Артоса. Кроме того, я сразу сделал более безопасным вызов обработки на отрегистрацию в гулагах. Вот, собственно, что в итоге получилось:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if (obj and obj.smart_terrain_id) then
local strn_id = 65535 -- значение по умолчанию

local t = nil -- сюда запихнём табличку из пакета
if IsStalker(obj) then t = m_net_utils.get_stalker_data(obj) elseif IsMonster(obj) then t = m_net_utils.get_monster_data(obj) end
-- вызываем парсинг пакета для неписей и монстров отдельно

-- print_table_inlog(t)
if t.smtrid then
strn_id = tonumber(t.smtrid) -- получаем идентификатор смарта, если его нету даже в пакете, хрен с ним, будет 65535
end

if strn_id ~= 65535 then -- если сняли идентификатор, попробуем отрегать...
local gulag = sim:object(strn_id)
if gulag and gulag.gulag then -- ...но сначала выясним если вообще такой гулаг и инициализирован ли он
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end
end</code>

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

<code>Description: xr_gulag:1035 value not found ObjectJobPathName[obj_id]</code>

'''Вернёшь строки на место, перестроишь текст - работает снова. Совершенная чертовщина, шаманил я над этой функцией около получаса, перестраивая текст таким образом чтобы игра нормально запускалась.''' Имейте это в виду когда в неё полезете и если что не пугайтесь если игра начнёт так вылетать - в этом случае пошаманьте немного над ней, меняя её форматирование. О причинах такого поведения я не могу даже догадываться - то ли движок её вызывает по смещению внутри файла вручную, то ли это какой-то баг Lua-парсера, но факт фактом.

Итак, теперь проблема с получением идентификатора смарта разрешилась, однако алайф всё равно зависал! Простая трассировка показала, что теперь зависание происходило внутри обработки

<code lua>sim:object(strn_id).gulag:clear_dead(obj_id)</code>

И мне пришлость распутывать её по частям, доискиваясь до причины. Обработка честно говоря мерзкая, размазана по smart_terrain и xr_gulag, при этом взаимные вызовы идут не менее десятка раз, в следующем стиле: ф-ция в смарте вызывает ф-цию в гулаге, которая вызывает фцию в смарте, которая обрабатывает параметр фцией в гулаге, который передётся ф-цией в логике, которая получает её из смарта. Нечто подобное. Опуская все нецензурные выражения, употребленные мной при трассировке, я лучше расскажу что собственно вышло в итоге. А в итоге я вышел вот на этот код в xr_gulag, именно в нём при отрегистрации некоторых мёртвых неписей происходит зависание алайфа:

<code lua>-- освободить объект от работы и переинициализировать логику.
-- если сталкер в онлайне и начал работу, то сбросить его схему поведения
-- как будто он только что загрузился
function gulag:free_obj_and_reinit( obj_id )
self:free_obj(obj_id)

local t = self.Object[obj_id]
if t ~= nil and t ~= true and self.Object_begin_job[obj_id] then
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) ) -- вот эта обработка вешает алайф
end
end</code>

Я, честно говоря, ни разу не понимаю, на кой чёрт нужно переконфигурировать схемы логики и выбирать из них активную '''трупу, который лежит себе спокойно и никого не трогает.''' Может быть в это есть некий высший смысл, или это было продиктовано неким аккуратизмом, однако одно я могу сказать однозначно - подобная переинициализация у некоторых трупов неписей приводит к глухому зависанию алайфа. При этом если для трупов эту обработку заблокировать, то трупы разрегистрируются вполне нормально и спокойно лежат с нетронутой логикой, не вызывая никаких проблем. Итоговый код после правок выглядит вот так:

<code lua>-- освободить объект от работы и переинициализировать логику.
-- если сталкер в онлайне и начал работу, то сбросить его схему поведения
-- как будто он только что загрузился
function gulag:free_obj_and_reinit( obj_id )
self:free_obj(obj_id)
local t = self.Object[obj_id]
if t ~= nil and t ~= true and self.Object_begin_job[obj_id] then
if check_game() then -- тут проверяется, запущена ли игра, если ли актор и жив ли он. Если да, делаем по новому.
local s_obj = alife():object(obj_id) -- проверим есть ли у цели разрегистрации валидный серверный объект
if s_obj and (IsStalker(s_obj) or IsMonster(s_obj)) and s_obj:alive() then -- если есть, он жив и сталкер или монстр
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) ) -- только тогда инициализируем логику
end
else -- а если игра не запущена, то как раньше. Это нужно для того, чтобы обработка запуска игры нормально работала.
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) )
end
end
end

-- Проверка, запущена ли игра
function check_game()
if level.present() and (db.actor ~= nil) and db.actor:alive() then
return true
end
return false
end
</code>

После этих поправок зависания алайфа при смерти неписей удалось побороть окончательно. Решение с отрезанием реинита логики для трупов несколько грубовато, но честно говоря, у меня нет ни малейшего желания трассировать и разбирать на части функцию xr_logic.initialize_obj, выясняя, чем же ей так данный конкретный труп не приглянулся. Если хотите - займитесь, найдёте причину - дополните данную статью. Я же успокоился на том, что заблокировал баг, периодически убивающий людям игру, так как многие пользователи, игнорируя предупреждения, играют на одном-двух сейвах, а то и вовсе на квиксейвах всю игру.

= Другие частые проблемы =

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

== Вылеты при удалении объектов из игры ==

При использовании для удаления объектов родной движковой функции '''alife():release(alife():object(id), true)''' возможен целый ворох разнообразнейших вылетов, обычно - безлоговых, что сильно затрудняет их отладку. Вот из-за чего они возникают:

1) Вылет при удалении непися или монстра, находящегося в онлайне.
Решение: с помощью alife():release '''можно удалять только мёртвые объекты'''. Поэтому если вам нужно удалить с её помощью непися или монстра, который жив и находится в онлайне, его нужно убить любым доступным методом, хотя бы нанеся ему hit() с любым запредельным уроном по вкусу.

2) Вылет при удалении оружия или артефакта.
Решение: такая проблема часто встречается в случае если объект неудачно расположен или находится в руках у непися. Для того чтобы не произошло вылета, убедитесь что объект доступен как серверный перед удалением. Вот так:

<code lua> local obj = alife():object(i)
if obj then
alife():release(obj, true)
end</code>

Эту конструкцию вообще желательно использовать всегда, когда вы так удаляете объекты.

3) Вылет при удалении аномалии.
Решение: аномалии - очень капризные при подобном с ними обращении объекты. Они влияют на своё окружение, и если рядом с ними находится непись или монстр, то удаление такой аномалии приведёт к вылету игры. Чтобы этого не произошло, аномалию надо сначала выключить функцией '''disable_anomaly''', и удалять затем ТОЛЬКО тогда, когда она не будет занята влиянием на динамический объект. Для этого нужно получить список мобов на локации, и из их нетпакетов считать идентификаторы действующих на них рестрикторов. Если ваша аномалия будет в этом списке - удалять её нельзя. Дождитесь пока она освободится.

== Вылет при открытии закладки "Контакты" в ПДА ==

Простой безлоговый вылет при открытии закладки "Контакты". Встречался во всех крупных модах, и никто не знал как его излечить. А лечится он банально - '''его причина - дублирование идентификаторов секций в XML-файле, описывающем иконки неписей для закладки "Контакты"'''. Нужно всего лишь проверить этот файл на наличие дублированных идентификаторов и удалить их. Вылет пропадёт и никогда больше не будет встречаться.

== Вылеты при вызове несуществующих функций из XML ==

В ХML-файлах, используемых для описания инфопоршенов, для многих инфопоршенов прописаны действия, которые игра вызывает при взятии этого инфопоршена. Вот так примерно:

<code xml>
<info_portion id="barman_document_have">
<action>dialogs.set_actor_prebandit1</action>
<action>bar_spawn.bandits2</action>
<action>bar_spawn.bandits3</action>
<action>bar_spawn.bandit7</action>
<action>bar_spawn.bandit8</action>
</info_portion>
</code>

Так вот, если вы допустите опечатку в названии вызываемой функции или же случайно её удалите - игра будет стабильно вылетать без лога при взятии этого инфопоршена.

== Повреждения сейвов на Радаре и других местах в модах, основанных на OGSM ==

В оригинале ОГСМ и основанных на нём модах часто встречались проблемы с сохранениями на Радаре. Эту проблему долго не удавалось победить, пока наконец благодаря помощи Маландринуса не удалось выявить её первопричину. Как выяснилось, она очень проста - гражданские зомби в моде (монстры) имели в конфиге ту же пропись вида (параметр конфига specie), что и монолитовцы и зомбированные (неписи). И там и тут было проставлено "zombie", и так оно было ещё с оригинала. Как оказалось, так делать категорически нельзя. Дело в том, что у неписей есть такой функционал, как хитовая память - в ней какое-то время хранятся ссылки на атакующие объекты. У монстров тоже есть остатки этого функционала, но он неработоспособен, и использовать его нельзя. В случае же когда монстры и неписи попадают в один вид, в ситуации когда они находятся рядом в бою, хитовая память монстров автоматически получает от неписей того же вида распространяемую внутри вида информацию об атакующих - а хранить её монстрам нельзя. Если после создания такой ситуации сохраниться - сейв будет вызывать вылет при загрузке. То есть проще говоря, если в бою с монолитовцами рядом оказывались гражданские зомби - и игрок сохранял игру - сейв этот не загружался. Чтобы предотвратить эти проблемы, вполне достаточно создать для гражданских зомби свой отдельный вид, добавив его прописи в конфиг game_relations.

== Застывания NPC после боя / лечения ранения в модах, использующих дополнительные схемы поведения ==

Во многих модах, использующих дополнительные схемы поведения часто можно заметить NPC, которые после боя застывают, прицелившись в одну точку. Аналогично часто это встречается с вылеченными от ранения NPC - они встают и замирают намертво, до тех пор пока их не выведет из этого состояния атаковавший враг. Как правило сейв/загрузка этой проблемы не решают. В ходе работы над OGSE 0.6.9.3 мне удалось выяснить причину таких проблем и успешно её устранить. Причина проблемы заключается в том, что NPC управляются не только скриптовыми схемами, но и движком, и для переключения управления между одним и другим используется скрипт ''state_mgr'' - менеджер состояний. Его директивы имеют наивысший приоритет. Аналогичный же приоритет себе как правило назначают доп. схемы поведения, используя пропись эвалуатора в ''xr_motivatior.addCommonPrecondition(action)''. В итоге при выходе из движковой боевки или при переключении на движковый алайф (это происходит после излечения ранения) доп. схемы поведения вступают с менеджером состояний в конфликт, блокируя смену состояния NPC. Для того чтобы этого не происходило, '''необходимо во всех схемах поведения, использующих принудительное назначение состояния через функцию ''state_mgr.set_state'' сделать блокировку перехвата управления менеджером состояний''', добавив соответствующие прописи в биндер. Вот таким образом, как в этом примере - тут я правил биндер схемы лечения/самолечения ''xrs_medic'':

<code lua>
function add_to_binder(object, ini, scheme, section, storage)
local operators = {}
local properties = {}

local manager = object:motivation_action_manager()

operators["medic"] = actid_medic
operators["self_medic"] = actid_self_medic

properties["medic"] = evid_medic
properties["self_medic"] = evid_self_medic

local state_mgr_to_idle_combat = xr_actions_id.state_mgr + 1 ---< Это переключение на движковую боевку, но оно тут не использовано
local state_mgr_to_idle_alife = xr_actions_id.state_mgr + 2 ---< Это переключение на движковый алайф
local state_mgr_to_idle_off = xr_actions_id.state_mgr + 3 ---< Это переключение в статичное состояние

local zombi=object:character_community()=="zombied" or object:character_community()=="trader" or
object:character_community()=="arena_enemy" or object:name()=="mil_stalker0012" or object:name()=="yantar_ecolog_general"

if zombi then
manager:add_evaluator (properties["medic"], property_evaluator_const(false))
manager:add_evaluator (properties["self_medic"], property_evaluator_const(false))
else
manager:add_evaluator (properties["medic"], evaluator_medic("medic", storage))
manager:add_evaluator (properties["self_medic"], evaluator_self_medic("self_medic", storage))
end

local action = action_medic (object,"medic", storage)
action:add_precondition(world_property(stalker_ids.property_alive, true))
action:add_precondition(world_property(xr_evaluators_id.sidor_wounded_base, false))
action:add_precondition (world_property(properties["medic"], true))
action:add_effect (world_property(properties["medic"], false))
manager:add_action (operators["medic"], action)

local action = action_self_medic (object,"self_medic", storage)
action:add_precondition(world_property(stalker_ids.property_alive, true))
action:add_precondition(world_property(stalker_ids.property_enemy,false))
action:add_precondition(world_property(xr_evaluators_id.sidor_wounded_base, false))
action:add_precondition (world_property(properties["medic"], false))
action:add_precondition (world_property(properties["self_medic"], true))
action:add_effect (world_property(properties["self_medic"], false))
manager:add_action (operators["self_medic"], action)

action = manager:action (stalker_ids.action_alife_planner)
action:add_precondition (world_property(properties["medic"], false))
action:add_precondition (world_property(properties["self_medic"], false))

action = manager:action(state_mgr_to_idle_alife)
action:add_precondition (world_property(properties["self_medic"], false)) ---< Блокируем попытки переключиться на движковый алайф пока работает самолечение

action = manager:action(state_mgr_to_idle_off)
action:add_precondition (world_property(properties["self_medic"], false)) ---< Блокируем попытки переключиться статичное состояние пока работает самолечение

end
</code>

Вставка этих директив в биндеры всех схем, которые меняют состояния принудительно устраняет конфликты, и NPC больше не виснут при смене схем.

== Зависания алайфа из-за ошибок в конфигах торговли ==

Очень частая проблема у начинающих модостроителей. Обнаруживается боем сейвов в радиусе алайфа от торговца с некорректным конфигом. Обычно главная и единственная причина этой проблемы - наличие в секции ''buy_supplies'' секций, у которых не прописан один или оба параметра, или же наличие записей вида

<code>
novice_outfit ;NO TRADE
</code>

Запомните - в секции ''buy_supplies'' конфига торговли таких записей быть не должно вообще. Если вы хотите убрать вещь из общего ассортимента - удалите её строку из ''buy_supplies''.

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 11:04, 31 марта 2011 (UTC)

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

[[Категория:Скрипты]]

Как писать скрипты, не приводящие к вылетам и бою сейвов (часть 2)

2011-03-31T11:57:57Z

Kamikazze: поправка

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Как безопасно использовать коллбэки и таймерные события =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Использование защищённого кода в LUA =

Периодически случаются такие ситуации, когда мы можем получить вылет при проверке аргумента, и не можем его адекватно заизолировать с помощью предварительной проверки на валидность значения. Вот простой пример: когда я отлаживал '''death_callback''' неписей, я периодически сталкивался с тем, что обращение к методу '''smart_terrain_id()''' при смерти непися иногда вызывало вылет

<code>smart_terrain:1143 "attempt to index a nil value"</code>

- хотя это свойство является родным методом объекта, и отсутствовать напрочь никак не может. В итоге я пришёл к выводу, что его просто иногда не успевает отработать движок, так как вылет этот проявлялся в основном в интенсивных боях и совершенно произвольно.

Вот код, в котором происходил вылет:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- вылет происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id)
end
end
end</code>

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

'''pcall (f, arg1, ···)'''

<blockquote>Вызывает функцию f с указанными через запятую аргументами в защищённом режиме. Это означает, что любая ошибка, даже критическая, внутри вызванной функции, не передаётся наружу - вызывавшей подсистеме. Вместо этого '''pcall''' перехватывает ошибку и возвращает код статуса. Первая возвращаемая переменная это сам код, (true или false) и если всё прошло хорошо, он равен true. В этом случае '''pcall''' сразу после статуса возвращает все результаты от работы защищённой им функции. Если же в защищённой функции произошла ошибка, то '''pcall''' вернёт false и затем сообщение об ошибке. (Обратите внимание, обработка ошибки присходит БЕЗ вылета! Вместо вылета вы получите вполне адекватную строку с ошибкой, которую можно вывести в лог для последующей обработки)</blockquote>

Я настоятельно советую пользоваться этой функцией в случаях, когда из коллбэков вызываются сложные комплексные обработки, вроде обработки из менеджера вооружений AI-пака. Это позволяет предотвратить как вылеты, так и зависания обработок, и в итоге позволяет хорошо стабилизировать игру.

Возвращаясь к нашим смарттеррейнам... вот как в итоге я подавил вылет типа smart_terrain:1143 с помощью pcall:

<code lua>--- эта функция пытается проверить св-во smart_terrain_id объекта. Именно её мы вызовем в защищённом режиме.
function prot_smt_td(obj)
if IsStalker(obj) or IsMonster(obj) then
return obj:smart_terrain_id()
else
return 65535
end
end

function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if obj then
local strn_id = 65535 --- предварительно проинитим переменную, на
--- случай если у нас prot_smt_td выдаст ошибку
local result, smt_id = pcall(prot_smt_td,obj) --- вызываем prot_smt_td в защищённом режиме
--- и сразу присваиваем его вывод переменным
if result then --- если pcall выдало true
strn_id = smt_id --- тогда применяем полученное значение
end
--- если же обработка выдаст ошибку, то strn_id останется неизменным...
if strn_id ~= 65535 then
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end</code>

В других местах это делается совершенно аналогично. Подробнее об этой и многих других функция для контроля кода, незаслуженно игнорируемых большинством моддеров, можно почитать тут: http://lua-users.org/wiki/FinalizedExceptions - на английском правда, но захотите - разберётесь, там всё просто.

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

= Скрытые критические проблемы в обработке вылетов игрой =

Ведя на днях отладку, выяснил в чём проблема с периодическим боем сейвов и многими другими заморочками как в оригинале игры, так и во многих модах... дело, как выяснилось, далеко не всегда в кривых руках. Есть такая стандартная ф-ция '''abort''' - предназначенная для выкидывания из игры, если что-то пошло не так. И как оказалось, она срабатывает далеко не всегда. Выяснилось это следующим образом:

В одном из логов нашего бета-тестера я увидел '''стандартное сообщение о вылете внутри рабочего лога'''... да-да, то самое которое '''FATAL ERROR''' и дальше по тексту. При этом игра у него НЕ вылетала, это сообщение об ошибке мы обнаружили позже, по случайности. Я заподозрил, что что-то не в порядке, и вставил внутрь этой ф-ции контрольную метку, кидавшую в консоль сообщение, в котором содержался паттерн сообщения об ошибке и само сообщение. Так вот, оказалось, что эта самая функция '''abort''' вызывается в игре с завидным постоянством (вы удивитесь насколько часто), когда возникают исключения в схемах логики, звука и т.д., но игра от этого вылетает на рабочий стол '''максимум только 3 раза из 10 вызовов'''. Вылет НЕ происходит обычно, когда функции передан паттерн ошибки, а остальные параметры пустые, такое бывает, и частенько. И если не сделать внутри этой функции особой метки для вывода в лог, как сделал это я, её вызовы проходят совершенно незаметно, и '''игра после критических ошибок продолжается как ни в чём ни бывало.''' А приводит это вот к чему... Внутри '''xr_logic''' в процедуре записи пстора (хранилища логики и флагов) неписей есть вызовы этого самого аборта в случае если на запись в пстор передана некорректная величина. Ну а так как аборт периодически вообще не срабатывает, то часто попадается ситуация, что неписям в пстор пишется полный ахтунг: куски кода из ОЗУ, всякая муть из лтх-ов, куски аллспавна, всё что угодно. Происходит это оттого, что кодер, писавший эту функцию ('''xr_logic.pstor_store(obj, varname, val)'''), явно и думать не думал что '''abort''' может не сработать. У него запись в пстор стояла после проверки, а не внутри неё (very bad idea), и если abort не срабатывал, игра писала в пстор мусор совершенно спокойно и незаметно для игрока. Потом вся эта хрень попадала прямо в сейвы. Вот проблемный код для наглядности:

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv) --- вот тут мы должны если что вылететь
end
db.storage[npc_id].pstor[varname] = val -- а если не вылетели, всё, получим запись в пстор левой мути
end</code>

Разумеется игра этим пстором в итоге давится, и сейвы сделанные после такой милой записи практически лопаются. Результат - "битые" (на самом деле подлежат реанимации) сейвы. Происходит это потому, что игра из сейва грузит неписям псторы сплошным чтением по словам, пока они не закончатся. В случае же если в псторе обнаруживается записанный ранее мусор, то обработка либо вылетает сразу, либо наглухо виснет, пытаясь запихать эдак с миллион слов в пстор особо отличившегося непися. Как вам например непись с размером пстора в 1697451 слова? В результате попытки его обработать игра просто на стадии синхронизации выжрала всю доступную ОЗУ и повисла.

Решение этой проблемы оказалось достатоно простым: во-первых я предположил максимальный размер полезной части пстора неписей в 20 слов r_u32() (пока ориентировочно, я ещё уточняю эту величину), и соответственно сделал остановку цикла загрузки пстора для неписей через 20 итераций. Там же, где в цикле стояла проверка на валидность записываемых данных (кстати тоже с вылетом в случае провала проверки), я сделал так, что если параметр не относится к валидному типу данных, то запись параметра в пстор не производится совсем. Это необходимо для того, чтобы если вдруг в сейве обнаружится мусор, то он был бы просто отброшен обработкой. Практика показала, что в итоге такие неписи вполне адекватны и в дальнейшем никаких проблем не вызывают, так как начало их пстора, с нормальными данными, обычно не повреждается - мусор дописывается после них, а не вместо них.

Ну и во-вторых модифицировал запись параметров в пстор, просто убрав запись под основание if-else так, чтобы если параметр неверен, он не записывался совсем. Теперь кстати, очень интересно, сохранились ли те же заморочки с ф-цией '''abort''' в Чистом Небе, и если да, то останутся ли в Зове Припяти?

------------

== Необходимые для стабилизации игры правки в модулях ==

'''Эта правка предотвращает запись в пстор если не сработал аборт:'''

''xr_logic.script''

'''Было:'''

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv)
end
db.storage[npc_id].pstor[varname] = val
end</code>

'''Стало:'''

<code lua>function pstor_store(obj, varname, val)
if not obj then return end
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
dgblog("xr_logic: pstor_store: not registered type encountered - write in pstor_store cancelled")
-- abort убран, так как один хрен не работает. Пусть тогда хотя бы в лог что-то валится.
else
db.storage[npc_id].pstor[varname] = val
-- вот так и только так. Если значение не валидно, ничего не происходит.
end
end</code>

'''А эта правка выкинет из пстора весь мусор при загрузке сейва, если он как-то в него попал'''

'''Было:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
abort("xr_logic: pstor_load_all: not registered type N %d encountered", tn)
end
printf("_bp: pstor_load_all: loaded [%s]='%s'", varname, utils.to_str(pstor[varname]))
end
end</code>

'''Стало:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
if tonumber(ctr) > 20 and tostring(obj:name()) ~= "single_player" and npc_id ~= db.actor:id() then
-- максимум 20 итераций - это число ещё уточняется, возможно понадобится больше
-- если у вас в пстор что-то свое пишется, ориентируйтесь на свои значения
-- и обязательно убираем из проверки актора - у него очень толстый пстор, и к тому же
-- если уж поврежденным будет его пстор, то тут точно уже ничего не поможет
dgblog("ОБНАРУЖЕН ОБЪЕКТ С ПОВРЕЖДЕННЫМ PSTOR: "..tostring(obj:name())..
" БУДЕТ ПРОИЗВЕДЕНА ПОПЫТКА ВОССТАНОВЛЕНИЯ")
ctr = 20
end
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
-- не надо пытаться вылетать - просто не пишем поврежденные данные
-- при этом обязательно удалять саму переменную - в результате записи
-- мусора в пстор одно только ее название может повесить загрузку
pstor[varname] = nil
end
end
end</code>

Эти примеры приведены для чистой игры. Единственное в чем не уверен пока, это в том, что максимум полезного размера - 20 слов. Возможно нужно выделить больше, это надо будет проверить ещё экспериментальным путем...

Кроме этого, советую ещё внутрь ф-ции abort вставить отладочные метки, чтобы точно знать когда она вызывалась. Настоятельно советую сделать это даже если вы матёрый моддер со стажем - гарантирую, будете неприятно удивлены.

Я это сделал вот так:

''_g.script''

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
end</code>

По поводу частичной неработоспособности ф-ции '''abort''' я беседовал с Колмогором, и он пришёл к выводу, что видимо вылет игры должен был бы производиться при обработке функции '''printf("%s")''' - ей тут передаётся заведомо отсутствующий оператор и она по уму должна бы сразу крашить игру. Однако в релизе функция printf фактически не работает(она реализована в _g.script через вырезанную функцию log). В результате игра не крашится. Но что поделать, в итоге мне пришлось модифицировать его таким образом, чтобы вылет при его срабатывании был гарантирован:

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
local crash
local ooops = 1/crash
end</code>

Вылет происходит при попытке произвести арифметическую операцию с неинициализированной переменной crash.

== Лечение зависаний алайфа при смерти персонажей ==

Недавно, отлаживая проблемы с зависанием алайфа, мне удалось найти причину этого периодически во всех модах всплывающего сбоя, приводящего к порче сейвов и сильно мешающего нормально играть. Сбой этот возникает при смерти некоторых NPC, обычно квестовых. В частности в моём случае изолировать и отладить это зависание удалось на Юрике, новичке со Свалке, учавствующем в сцене с гоп-стопом. Причина оказалась в обработке посмертной отрегистрации NPC из гулагов, причём сбой там был настоящей матрёшкой, составной из нескольких частей. Правок в итоге было совсем немного, но чтобы сделать их мне пришлось несколько часов распутывать клубок из кросс-вызовов между скриптами smart_terrain и xr_gulag. Итак, начнём с самого начала. Работая над OGSE 069 и 0691 я периодически сталкивался с зависаниями и вылетами в посмертных обработках неписей. Один из таких вылетов - всем хорошо знакомый вылет:

<code>smart_terrain:1143 "attempt to index a nil value"</code>

Происходящий в функции '''smart_terrain.on_death( obj_id )''' - я тогда его заблокировал вызовом его внутри безопасного кода функцией '''pcall''', однако, как теперь выяснилось, этого оказалось недостаточно - баг тут состоит из нескольких частей, и этот вылет указывает только на одну из них. Вот исходный код:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- первый вылет/зависнаие алайфа происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id) -- а вот в этой обработке происходит зависание алайфа. Она очень комплексная, и её сложно распутывать.
end
end
end</code>

Во-первых выяснилось, что изредка вызов '''obj:smart_terrain_id()''' вызывает зависание алайфа даже когда он производится изнутри защищённого кода. Тогда я решил избавиться от использования этой функции в данном месте совсем. После нескольких экспериментов выяснилось, что самым простым, быстрым и вылетобезопасным способом будет считать нетпакет существа в таблицу и выудить идентификатор смарттеррейна из неё. Для этого можно написать свою обработку, однако я, как весьма ленивый программист, не склонен изобретать велосипеды, поэтому я воспользовался уже проверенной у нас и активно используемой в OGSE библиотекой функций для работы с нетпакетами '''m_net_utils''' Артоса. Кроме того, я сразу сделал более безопасным вызов обработки на отрегистрацию в гулагах. Вот, собственно, что в итоге получилось:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if (obj and obj.smart_terrain_id) then
local strn_id = 65535 -- значение по умолчанию

local t = nil -- сюда запихнём табличку из пакета
if IsStalker(obj) then t = m_net_utils.get_stalker_data(obj) elseif IsMonster(obj) then t = m_net_utils.get_monster_data(obj) end
-- вызываем парсинг пакета для неписей и монстров отдельно

-- print_table_inlog(t)
if t.smtrid then
strn_id = tonumber(t.smtrid) -- получаем идентификатор смарта, если его нету даже в пакете, хрен с ним, будет 65535
end

if strn_id ~= 65535 then -- если сняли идентификатор, попробуем отрегать...
local gulag = sim:object(strn_id)
if gulag and gulag.gulag then -- ...но сначала выясним если вообще такой гулаг и инициализирован ли он
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end
end</code>

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

<code>Description: xr_gulag:1035 value not found ObjectJobPathName[obj_id]</code>

'''Вернёшь строки на место, перестроишь текст - работает снова. Совершенная чертовщина, шаманил я над этой функцией около получаса, перестраивая текст таким образом чтобы игра нормально запускалась.''' Имейте это в виду когда в неё полезете и если что не пугайтесь если игра начнёт так вылетать - в этом случае пошаманьте немного над ней, меняя её форматирование. О причинах такого поведения я не могу даже догадываться - то ли движок её вызывает по смещению внутри файла вручную, то ли это какой-то баг Lua-парсера, но факт фактом.

Итак, теперь проблема с получением идентификатора смарта разрешилась, однако алайф всё равно зависал! Простая трассировка показала, что теперь зависание происходило внутри обработки

<code lua>sim:object(strn_id).gulag:clear_dead(obj_id)</code>

И мне пришлость распутывать её по частям, доискиваясь до причины. Обработка честно говоря мерзкая, размазана по smart_terrain и xr_gulag, при этом взаимные вызовы идут не менее десятка раз, в следующем стиле: ф-ция в смарте вызывает ф-цию в гулаге, которая вызывает фцию в смарте, которая обрабатывает параметр фцией в гулаге, который передётся ф-цией в логике, которая получает её из смарта. Нечто подобное. Опуская все нецензурные выражения, употребленные мной при трассировке, я лучше расскажу что собственно вышло в итоге. А в итоге я вышел вот на этот код в xr_gulag, именно в нём при отрегистрации некоторых мёртвых неписей происходит зависание алайфа:

<code lua>-- освободить объект от работы и переинициализировать логику.
-- если сталкер в онлайне и начал работу, то сбросить его схему поведения
-- как будто он только что загрузился
function gulag:free_obj_and_reinit( obj_id )
self:free_obj(obj_id)

local t = self.Object[obj_id]
if t ~= nil and t ~= true and self.Object_begin_job[obj_id] then
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) ) -- вот эта обработка вешает алайф
end
end</code>

Я, честно говоря, ни разу не понимаю, на кой чёрт нужно переконфигурировать схемы логики и выбирать из них активную '''трупу, который лежит себе спокойно и никого не трогает.''' Может быть в это есть некий высший смысл, или это было продиктовано неким аккуратизмом, однако одно я могу сказать однозначно - подобная переинициализация у некоторых трупов неписей приводит к глухому зависанию алайфа. При этом если для трупов эту обработку заблокировать, то трупы разрегистрируются вполне нормально и спокойно лежат с нетронутой логикой, не вызывая никаких проблем. Итоговый код после правок выглядит вот так:

<code lua>-- освободить объект от работы и переинициализировать логику.
-- если сталкер в онлайне и начал работу, то сбросить его схему поведения
-- как будто он только что загрузился
function gulag:free_obj_and_reinit( obj_id )
self:free_obj(obj_id)
local t = self.Object[obj_id]
if t ~= nil and t ~= true and self.Object_begin_job[obj_id] then
if check_game() then -- тут проверяется, запущена ли игра, если ли актор и жив ли он. Если да, делаем по новому.
local s_obj = alife():object(obj_id) -- проверим есть ли у цели разрегистрации валидный серверный объект
if s_obj and (IsStalker(s_obj) or IsMonster(s_obj)) and s_obj:alive() then -- если есть, он жив и сталкер или монстр
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) ) -- только тогда инициализируем логику
end
else -- а если игра не запущена, то как раньше. Это нужно для того, чтобы обработка запуска игры нормально работала.
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) )
end
end
end

-- Проверка, запущена ли игра
function check_game()
if level.present() and (db.actor ~= nil) and db.actor:alive() then
return true
end
return false
end
</code>

После этих поправок зависания алайфа при смерти неписей удалось побороть окончательно. Решение с отрезанием реинита логики для трупов несколько грубовато, но честно говоря, у меня нет ни малейшего желания трассировать и разбирать на части функцию xr_logic.initialize_obj, выясняя, чем же ей так данный конкретный труп не приглянулся. Если хотите - займитесь, найдёте причину - дополните данную статью. Я же успокоился на том, что заблокировал баг, периодически убивающий людям игру, так как многие пользователи, игнорируя предупреждения, играют на одном-двух сейвах, а то и вовсе на квиксейвах всю игру.

= Другие частые проблемы =

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

== Вылеты при удалении объектов из игры ==

При использовании для удаления объектов родной движковой функции '''alife():release(alife():object(id), true)''' возможен целый ворох разнообразнейших вылетов, обычно - безлоговых, что сильно затрудняет их отладку. Вот из-за чего они возникают:

1) Вылет при удалении непися или монстра, находящегося в онлайне.
Решение: с помощью alife():release '''можно удалять только мёртвые объекты'''. Поэтому если вам нужно удалить с её помощью непися или монстра, который жив и находится в онлайне, его нужно убить любым доступным методом, хотя бы нанеся ему hit() с любым запредельным уроном по вкусу.

2) Вылет при удалении оружия или артефакта.
Решение: такая проблема часто встречается в случае если объект неудачно расположен или находится в руках у непися. Для того чтобы не произошло вылета, убедитесь что объект доступен как серверный перед удалением. Вот так:

<code lua> local obj = alife():object(i)
if obj then
alife():release(obj, true)
end</code>

Эту конструкцию вообще желательно использовать всегда, когда вы так удаляете объекты.

3) Вылет при удалении аномалии.
Решение: аномалии - очень капризные при подобном с ними обращении объекты. Они влияют на своё окружение, и если рядом с ними находится непись или монстр, то удаление такой аномалии приведёт к вылету игры. Чтобы этого не произошло, аномалию надо сначала выключить функцией '''disable_anomaly''', и удалять затем ТОЛЬКО тогда, когда она не будет занята влиянием на динамический объект. Для этого нужно получить список мобов на локации, и из их нетпакетов считать идентификаторы действующих на них рестрикторов. Если ваша аномалия будет в этом списке - удалять её нельзя. Дождитесь пока она освободится.

== Вылет при открытии закладки "Контакты" в ПДА ==

Простой безлоговый вылет при открытии закладки "Контакты". Встречался во всех крупных модах, и никто не знал как его излечить. А лечится он банально - '''его причина - дублирование идентификаторов секций в XML-файле, описывающем иконки неписей для закладки "Контакты"'''. Нужно всего лишь проверить этот файл на наличие дублированных идентификаторов и удалить их. Вылет пропадёт и никогда больше не будет встречаться.

== Вылеты при вызове несуществующих функций из XML ==

В ХML-файлах, используемых для описания инфопоршенов, для многих инфопоршенов прописаны действия, которые игра вызывает при взятии этого инфопоршена. Вот так примерно:

<code xml>
<info_portion id="barman_document_have">
<action>dialogs.set_actor_prebandit1</action>
<action>bar_spawn.bandits2</action>
<action>bar_spawn.bandits3</action>
<action>bar_spawn.bandit7</action>
<action>bar_spawn.bandit8</action>
</info_portion>
</code>

Так вот, если вы допустите опечатку в названии вызываемой функции или же случайно её удалите - игра будет стабильно вылетать без лога при взятии этого инфопоршена.

== Повреждения сейвов на Радаре и других местах в модах, основанных на OGSM ==

В оригинале ОГСМ и основанных на нём модах часто встречались проблемы с сохранениями на Радаре. Эту проблему долго не удавалось победить, пока наконец благодаря помощи Маландринуса не удалось выявить её первопричину. Как выяснилось, она очень проста - гражданские зомби в моде (монстры) имели в конфиге ту же пропись вида (параметр конфига specie), что и монолитовцы и зомбированные (неписи). И там и тут было проставлено "zombie", и так оно было ещё с оригинала. Как оказалось, так делать категорически нельзя. Дело в том, что у неписей есть такой функционал, как хитовая память - в ней какое-то время хранятся ссылки на атакующие объекты. У монстров тоже есть остатки этого функционала, но он неработоспособен, и использовать его нельзя. В случае же когда монстры и неписи попадают в один вид, в ситуации когда они находятся рядом в бою, хитовая память монстров автоматически получает от неписей того же вида распространяемую внутри вида информацию об атакующих - а хранить её монстрам нельзя. Если после создания такой ситуации сохраниться - сейв будет вызывать вылет при загрузке. То есть проще говоря, если в бою с монолитовцами рядом оказывались гражданские зомби - и игрок сохранял игру - сейв этот не загружался. Чтобы предотвратить эти проблемы, вполне достаточно создать для гражданских зомби свой отдельный вид, добавив его прописи в конфиг game_relations.

== Застывания NPC после боя / лечения ранения в модах, использующих дополнительные схемы поведения ==

Во многих модах, использующих дополнительные схемы поведения часто можно заметить NPC, которые после боя застывают, прицелившись в одну точку. Аналогично часто это встречается с вылеченными от ранения NPC - они встают и замирают намертво, до тех пор пока их не выведет из этого состояния атаковавший враг. Как правило сейв/загрузка этой проблемы не решают. В ходе работы над OGSE 0.6.9.3 мне удалось выяснить причину таких проблем и успешно её устранить. Причина проблемы заключается в том, что NPC управляются не только скриптовыми схемами, но и движком, и для переключения управления между одним и другим используется скрипт ''state_mgr'' - менеджер состояний. Его директивы имеют наивысший приоритет. Аналогичный же приоритет себе как правило назначают доп. схемы поведения, используя пропись эвалуатора в ''xr_motivatior.addCommonPrecondition(action)''. В итоге при выходе из движковой боевки или при переключении на движковый алайф (это происходит после излечения ранения) доп. схемы поведения вступают с менеджером состояний в конфликт, блокируя смену состояния NPC. Для того чтобы этого не происходило, '''необходимо во всех схемах поведения, использующих принудительное назначение состояния через функцию ''state_mgr.set_state'' сделать блокировку перехвата управления менеджером состояний''', добавив соответствующие прописи в биндер. Вот таким образом, как в этом примере - тут я правил биндер схемы лечения/самолечения ''xrs_medic'':

<code lua>
function add_to_binder(object, ini, scheme, section, storage)
local operators = {}
local properties = {}

local manager = object:motivation_action_manager()

operators["medic"] = actid_medic
operators["self_medic"] = actid_self_medic

properties["medic"] = evid_medic
properties["self_medic"] = evid_self_medic

local state_mgr_to_idle_combat = xr_actions_id.state_mgr + 1 ---< Это переключение на движковую боевку, но оно тут не использовано
local state_mgr_to_idle_alife = xr_actions_id.state_mgr + 2 ---< Это переключение на движковый алайф
local state_mgr_to_idle_off = xr_actions_id.state_mgr + 3 ---< Это переключение в статичное состояние

local zombi=object:character_community()=="zombied" or object:character_community()=="trader" or
object:character_community()=="arena_enemy" or object:name()=="mil_stalker0012" or object:name()=="yantar_ecolog_general"

if zombi then
manager:add_evaluator (properties["medic"], property_evaluator_const(false))
manager:add_evaluator (properties["self_medic"], property_evaluator_const(false))
else
manager:add_evaluator (properties["medic"], evaluator_medic("medic", storage))
manager:add_evaluator (properties["self_medic"], evaluator_self_medic("self_medic", storage))
end

local action = action_medic (object,"medic", storage)
action:add_precondition(world_property(stalker_ids.property_alive, true))
action:add_precondition(world_property(xr_evaluators_id.sidor_wounded_base, false))
action:add_precondition (world_property(properties["medic"], true))
action:add_effect (world_property(properties["medic"], false))
manager:add_action (operators["medic"], action)

local action = action_self_medic (object,"self_medic", storage)
action:add_precondition(world_property(stalker_ids.property_alive, true))
action:add_precondition(world_property(stalker_ids.property_enemy,false))
action:add_precondition(world_property(xr_evaluators_id.sidor_wounded_base, false))
action:add_precondition (world_property(properties["medic"], false))
action:add_precondition (world_property(properties["self_medic"], true))
action:add_effect (world_property(properties["self_medic"], false))
manager:add_action (operators["self_medic"], action)

action = manager:action (stalker_ids.action_alife_planner)
action:add_precondition (world_property(properties["medic"], false))
action:add_precondition (world_property(properties["self_medic"], false))

action = manager:action(state_mgr_to_idle_alife)
action:add_precondition (world_property(properties["self_medic"], false)) ---< Блокируем попытки переключиться на движковый алайф пока работает самолечение

action = manager:action(state_mgr_to_idle_off)
action:add_precondition (world_property(properties["self_medic"], false)) ---< Блокируем попытки переключиться статичное состояние пока работает самолечение

end
</code>

Вставка этих директив в биндеры всех схем, которые меняют состояния принудительно устраняет конфликты, и NPC больше не виснут при смене схем.

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 11:04, 31 марта 2011 (UTC)

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

[[Категория:Скрипты]]

Как писать скрипты, не приводящие к вылетам и бою сейвов (часть 2)

2011-03-31T11:56:34Z

Kamikazze: Добавлено решение проблемы зависания NPC, дополнение

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Как безопасно использовать коллбэки и таймерные события =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Использование защищённого кода в LUA =

Периодически случаются такие ситуации, когда мы можем получить вылет при проверке аргумента, и не можем его адекватно заизолировать с помощью предварительной проверки на валидность значения. Вот простой пример: когда я отлаживал '''death_callback''' неписей, я периодически сталкивался с тем, что обращение к методу '''smart_terrain_id()''' при смерти непися иногда вызывало вылет

<code>smart_terrain:1143 "attempt to index a nil value"</code>

- хотя это свойство является родным методом объекта, и отсутствовать напрочь никак не может. В итоге я пришёл к выводу, что его просто иногда не успевает отработать движок, так как вылет этот проявлялся в основном в интенсивных боях и совершенно произвольно.

Вот код, в котором происходил вылет:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- вылет происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id)
end
end
end</code>

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

'''pcall (f, arg1, ···)'''

<blockquote>Вызывает функцию f с указанными через запятую аргументами в защищённом режиме. Это означает, что любая ошибка, даже критическая, внутри вызванной функции, не передаётся наружу - вызывавшей подсистеме. Вместо этого '''pcall''' перехватывает ошибку и возвращает код статуса. Первая возвращаемая переменная это сам код, (true или false) и если всё прошло хорошо, он равен true. В этом случае '''pcall''' сразу после статуса возвращает все результаты от работы защищённой им функции. Если же в защищённой функции произошла ошибка, то '''pcall''' вернёт false и затем сообщение об ошибке. (Обратите внимание, обработка ошибки присходит БЕЗ вылета! Вместо вылета вы получите вполне адекватную строку с ошибкой, которую можно вывести в лог для последующей обработки)</blockquote>

Я настоятельно советую пользоваться этой функцией в случаях, когда из коллбэков вызываются сложные комплексные обработки, вроде обработки из менеджера вооружений AI-пака. Это позволяет предотвратить как вылеты, так и зависания обработок, и в итоге позволяет хорошо стабилизировать игру.

Возвращаясь к нашим смарттеррейнам... вот как в итоге я подавил вылет типа smart_terrain:1143 с помощью pcall:

<code lua>--- эта функция пытается проверить св-во smart_terrain_id объекта. Именно её мы вызовем в защищённом режиме.
function prot_smt_td(obj)
if IsStalker(obj) or IsMonster(obj) then
return obj:smart_terrain_id()
else
return 65535
end
end

function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if obj then
local strn_id = 65535 --- предварительно проинитим переменную, на
--- случай если у нас prot_smt_td выдаст ошибку
local result, smt_id = pcall(prot_smt_td,obj) --- вызываем prot_smt_td в защищённом режиме
--- и сразу присваиваем его вывод переменным
if result then --- если pcall выдало true
strn_id = smt_id --- тогда применяем полученное значение
end
--- если же обработка выдаст ошибку, то strn_id останется неизменным...
if strn_id ~= 65535 then
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end</code>

В других местах это делается совершенно аналогично. Подробнее об этой и многих других функция для контроля кода, незаслуженно игнорируемых большинством моддеров, можно почитать тут: http://lua-users.org/wiki/FinalizedExceptions - на английском правда, но захотите - разберётесь, там всё просто.

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

= Скрытые критические проблемы в обработке вылетов игрой =

Ведя на днях отладку, выяснил в чём проблема с периодическим боем сейвов и многими другими заморочками как в оригинале игры, так и во многих модах... дело, как выяснилось, далеко не всегда в кривых руках. Есть такая стандартная ф-ция '''abort''' - предназначенная для выкидывания из игры, если что-то пошло не так. И как оказалось, она срабатывает далеко не всегда. Выяснилось это следующим образом:

В одном из логов нашего бета-тестера я увидел '''стандартное сообщение о вылете внутри рабочего лога'''... да-да, то самое которое '''FATAL ERROR''' и дальше по тексту. При этом игра у него НЕ вылетала, это сообщение об ошибке мы обнаружили позже, по случайности. Я заподозрил, что что-то не в порядке, и вставил внутрь этой ф-ции контрольную метку, кидавшую в консоль сообщение, в котором содержался паттерн сообщения об ошибке и само сообщение. Так вот, оказалось, что эта самая функция '''abort''' вызывается в игре с завидным постоянством (вы удивитесь насколько часто), когда возникают исключения в схемах логики, звука и т.д., но игра от этого вылетает на рабочий стол '''максимум только 3 раза из 10 вызовов'''. Вылет НЕ происходит обычно, когда функции передан паттерн ошибки, а остальные параметры пустые, такое бывает, и частенько. И если не сделать внутри этой функции особой метки для вывода в лог, как сделал это я, её вызовы проходят совершенно незаметно, и '''игра после критических ошибок продолжается как ни в чём ни бывало.''' А приводит это вот к чему... Внутри '''xr_logic''' в процедуре записи пстора (хранилища логики и флагов) неписей есть вызовы этого самого аборта в случае если на запись в пстор передана некорректная величина. Ну а так как аборт периодически вообще не срабатывает, то часто попадается ситуация, что неписям в пстор пишется полный ахтунг: куски кода из ОЗУ, всякая муть из лтх-ов, куски аллспавна, всё что угодно. Происходит это оттого, что кодер, писавший эту функцию ('''xr_logic.pstor_store(obj, varname, val)'''), явно и думать не думал что '''abort''' может не сработать. У него запись в пстор стояла после проверки, а не внутри неё (very bad idea), и если abort не срабатывал, игра писала в пстор мусор совершенно спокойно и незаметно для игрока. Потом вся эта хрень попадала прямо в сейвы. Вот проблемный код для наглядности:

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv) --- вот тут мы должны если что вылететь
end
db.storage[npc_id].pstor[varname] = val -- а если не вылетели, всё, получим запись в пстор левой мути
end</code>

Разумеется игра этим пстором в итоге давится, и сейвы сделанные после такой милой записи практически лопаются. Результат - "битые" (на самом деле подлежат реанимации) сейвы. Происходит это потому, что игра из сейва грузит неписям псторы сплошным чтением по словам, пока они не закончатся. В случае же если в псторе обнаруживается записанный ранее мусор, то обработка либо вылетает сразу, либо наглухо виснет, пытаясь запихать эдак с миллион слов в пстор особо отличившегося непися. Как вам например непись с размером пстора в 1697451 слова? В результате попытки его обработать игра просто на стадии синхронизации выжрала всю доступную ОЗУ и повисла.

Решение этой проблемы оказалось достатоно простым: во-первых я предположил максимальный размер полезной части пстора неписей в 20 слов r_u32() (пока ориентировочно, я ещё уточняю эту величину), и соответственно сделал остановку цикла загрузки пстора для неписей через 20 итераций. Там же, где в цикле стояла проверка на валидность записываемых данных (кстати тоже с вылетом в случае провала проверки), я сделал так, что если параметр не относится к валидному типу данных, то запись параметра в пстор не производится совсем. Это необходимо для того, чтобы если вдруг в сейве обнаружится мусор, то он был бы просто отброшен обработкой. Практика показала, что в итоге такие неписи вполне адекватны и в дальнейшем никаких проблем не вызывают, так как начало их пстора, с нормальными данными, обычно не повреждается - мусор дописывается после них, а не вместо них.

Ну и во-вторых модифицировал запись параметров в пстор, просто убрав запись под основание if-else так, чтобы если параметр неверен, он не записывался совсем. Теперь кстати, очень интересно, сохранились ли те же заморочки с ф-цией '''abort''' в Чистом Небе, и если да, то останутся ли в Зове Припяти?

------------

== Необходимые для стабилизации игры правки в модулях ==

'''Эта правка предотвращает запись в пстор если не сработал аборт:'''

''xr_logic.script''

'''Было:'''

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv)
end
db.storage[npc_id].pstor[varname] = val
end</code>

'''Стало:'''

<code lua>function pstor_store(obj, varname, val)
if not obj then return end
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
dgblog("xr_logic: pstor_store: not registered type encountered - write in pstor_store cancelled")
-- abort убран, так как один хрен не работает. Пусть тогда хотя бы в лог что-то валится.
else
db.storage[npc_id].pstor[varname] = val
-- вот так и только так. Если значение не валидно, ничего не происходит.
end
end</code>

'''А эта правка выкинет из пстора весь мусор при загрузке сейва, если он как-то в него попал'''

'''Было:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
abort("xr_logic: pstor_load_all: not registered type N %d encountered", tn)
end
printf("_bp: pstor_load_all: loaded [%s]='%s'", varname, utils.to_str(pstor[varname]))
end
end</code>

'''Стало:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
if tonumber(ctr) > 20 and tostring(obj:name()) ~= "single_player" and npc_id ~= db.actor:id() then
-- максимум 20 итераций - это число ещё уточняется, возможно понадобится больше
-- если у вас в пстор что-то свое пишется, ориентируйтесь на свои значения
-- и обязательно убираем из проверки актора - у него очень толстый пстор, и к тому же
-- если уж поврежденным будет его пстор, то тут точно уже ничего не поможет
dgblog("ОБНАРУЖЕН ОБЪЕКТ С ПОВРЕЖДЕННЫМ PSTOR: "..tostring(obj:name())..
" БУДЕТ ПРОИЗВЕДЕНА ПОПЫТКА ВОССТАНОВЛЕНИЯ")
ctr = 20
end
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
-- не надо пытаться вылетать - просто не пишем поврежденные данные
-- при этом обязательно удалять саму переменную - в результате записи
-- мусора в пстор одно только ее название может повесить загрузку
pstor[varname] = nil
end
end
end</code>

Эти примеры приведены для чистой игры. Единственное в чем не уверен пока, это в том, что максимум полезного размера - 20 слов. Возможно нужно выделить больше, это надо будет проверить ещё экспериментальным путем...

Кроме этого, советую ещё внутрь ф-ции abort вставить отладочные метки, чтобы точно знать когда она вызывалась. Настоятельно советую сделать это даже если вы матёрый моддер со стажем - гарантирую, будете неприятно удивлены.

Я это сделал вот так:

''_g.script''

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
end</code>

По поводу частичной неработоспособности ф-ции '''abort''' я беседовал с Колмогором, и он пришёл к выводу, что видимо вылет игры должен был бы производиться при обработке функции '''printf("%s")''' - ей тут передаётся заведомо отсутствующий оператор и она по уму должна бы сразу крашить игру. Однако в релизе функция printf фактически не работает(она реализована в _g.script через вырезанную функцию log). В результате игра не крашится. Но что поделать, в итоге мне пришлось модифицировать его таким образом, чтобы вылет при его срабатывании был гарантирован:

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
local crash
local ooops = 1/crash
end</code>

Вылет происходит при попытке произвести арифметическую операцию с неинициализированной переменной crash.

== Лечение зависаний алайфа при смерти персонажей ==

Недавно, отлаживая проблемы с зависанием алайфа, мне удалось найти причину этого периодически во всех модах всплывающего сбоя, приводящего к порче сейвов и сильно мешающего нормально играть. Сбой этот возникает при смерти некоторых NPC, обычно квестовых. В частности в моём случае изолировать и отладить это зависание удалось на Юрике, новичке со Свалке, учавствующем в сцене с гоп-стопом. Причина оказалась в обработке посмертной отрегистрации NPC из гулагов, причём сбой там был настоящей матрёшкой, составной из нескольких частей. Правок в итоге было совсем немного, но чтобы сделать их мне пришлось несколько часов распутывать клубок из кросс-вызовов между скриптами smart_terrain и xr_gulag. Итак, начнём с самого начала. Работая над OGSE 069 и 0691 я периодически сталкивался с зависаниями и вылетами в посмертных обработках неписей. Один из таких вылетов - всем хорошо знакомый вылет:

<code>smart_terrain:1143 "attempt to index a nil value"</code>

Происходящий в функции '''smart_terrain.on_death( obj_id )''' - я тогда его заблокировал вызовом его внутри безопасного кода функцией '''pcall''', однако, как теперь выяснилось, этого оказалось недостаточно - баг тут состоит из нескольких частей, и этот вылет указывает только на одну из них. Вот исходный код:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- первый вылет/зависнаие алайфа происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id) -- а вот в этой обработке происходит зависание алайфа. Она очень комплексная, и её сложно распутывать.
end
end
end</code>

Во-первых выяснилось, что изредка вызов '''obj:smart_terrain_id()''' вызывает зависание алайфа даже когда он производится изнутри защищённого кода. Тогда я решил избавиться от использования этой функции в данном месте совсем. После нескольких экспериментов выяснилось, что самым простым, быстрым и вылетобезопасным способом будет считать нетпакет существа в таблицу и выудить идентификатор смарттеррейна из неё. Для этого можно написать свою обработку, однако я, как весьма ленивый программист, не склонен изобретать велосипеды, поэтому я воспользовался уже проверенной у нас и активно используемой в OGSE библиотекой функций для работы с нетпакетами '''m_net_utils''' Артоса. Кроме того, я сразу сделал более безопасным вызов обработки на отрегистрацию в гулагах. Вот, собственно, что в итоге получилось:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if (obj and obj.smart_terrain_id) then
local strn_id = 65535 -- значение по умолчанию

local t = nil -- сюда запихнём табличку из пакета
if IsStalker(obj) then t = m_net_utils.get_stalker_data(obj) elseif IsMonster(obj) then t = m_net_utils.get_monster_data(obj) end
-- вызываем парсинг пакета для неписей и монстров отдельно

-- print_table_inlog(t)
if t.smtrid then
strn_id = tonumber(t.smtrid) -- получаем идентификатор смарта, если его нету даже в пакете, хрен с ним, будет 65535
end

if strn_id ~= 65535 then -- если сняли идентификатор, попробуем отрегать...
local gulag = sim:object(strn_id)
if gulag and gulag.gulag then -- ...но сначала выясним если вообще такой гулаг и инициализирован ли он
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end
end</code>

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

<code>Description: xr_gulag:1035 value not found ObjectJobPathName[obj_id]</code>

'''Вернёшь строки на место, перестроишь текст - работает снова. Совершенная чертовщина, шаманил я над этой функцией около получаса, перестраивая текст таким образом чтобы игра нормально запускалась.''' Имейте это в виду когда в неё полезете и если что не пугайтесь если игра начнёт так вылетать - в этом случае пошаманьте немного над ней, меняя её форматирование. О причинах такого поведения я не могу даже догадываться - то ли движок её вызывает по смещению внутри файла вручную, то ли это какой-то баг Lua-парсера, но факт фактом.

Итак, теперь проблема с получением идентификатора смарта разрешилась, однако алайф всё равно зависал! Простая трассировка показала, что теперь зависание происходило внутри обработки

<code lua>sim:object(strn_id).gulag:clear_dead(obj_id)</code>

И мне пришлость распутывать её по частям, доискиваясь до причины. Обработка честно говоря мерзкая, размазана по smart_terrain и xr_gulag, при этом взаимные вызовы идут не менее десятка раз, в следующем стиле: ф-ция в смарте вызывает ф-цию в гулаге, которая вызывает фцию в смарте, которая обрабатывает параметр фцией в гулаге, который передётся ф-цией в логике, которая получает её из смарта. Нечто подобное. Опуская все нецензурные выражения, употребленные мной при трассировке, я лучше расскажу что собственно вышло в итоге. А в итоге я вышел вот на этот код в xr_gulag, именно в нём при отрегистрации некоторых мёртвых неписей происходит зависание алайфа:

<code lua>-- освободить объект от работы и переинициализировать логику.
-- если сталкер в онлайне и начал работу, то сбросить его схему поведения
-- как будто он только что загрузился
function gulag:free_obj_and_reinit( obj_id )
self:free_obj(obj_id)

local t = self.Object[obj_id]
if t ~= nil and t ~= true and self.Object_begin_job[obj_id] then
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) ) -- вот эта обработка вешает алайф
end
end</code>

Я, честно говоря, ни разу не понимаю, на кой чёрт нужно переконфигурировать схемы логики и выбирать из них активную '''трупу, который лежит себе спокойно и никого не трогает.''' Может быть в это есть некий высший смысл, или это было продиктовано неким аккуратизмом, однако одно я могу сказать однозначно - подобная переинициализация у некоторых трупов неписей приводит к глухому зависанию алайфа. При этом если для трупов эту обработку заблокировать, то трупы разрегистрируются вполне нормально и спокойно лежат с нетронутой логикой, не вызывая никаких проблем. Итоговый код после правок выглядит вот так:

<code lua>-- освободить объект от работы и переинициализировать логику.
-- если сталкер в онлайне и начал работу, то сбросить его схему поведения
-- как будто он только что загрузился
function gulag:free_obj_and_reinit( obj_id )
self:free_obj(obj_id)
local t = self.Object[obj_id]
if t ~= nil and t ~= true and self.Object_begin_job[obj_id] then
if check_game() then -- тут проверяется, запущена ли игра, если ли актор и жив ли он. Если да, делаем по новому.
local s_obj = alife():object(obj_id) -- проверим есть ли у цели разрегистрации валидный серверный объект
if s_obj and (IsStalker(s_obj) or IsMonster(s_obj)) and s_obj:alive() then -- если есть, он жив и сталкер или монстр
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) ) -- только тогда инициализируем логику
end
else -- а если игра не запущена, то как раньше. Это нужно для того, чтобы обработка запуска игры нормально работала.
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) )
end
end
end

-- Проверка, запущена ли игра
function check_game()
if level.present() and (db.actor ~= nil) and db.actor:alive() then
return true
end
return false
end
</code>

После этих поправок зависания алайфа при смерти неписей удалось побороть окончательно. Решение с отрезанием реинита логики для трупов несколько грубовато, но честно говоря, у меня нет ни малейшего желания трассировать и разбирать на части функцию xr_logic.initialize_obj, выясняя, чем же ей так данный конкретный труп не приглянулся. Если хотите - займитесь, найдёте причину - дополните данную статью. Я же успокоился на том, что заблокировал баг, периодически убивающий людям игру, так как многие пользователи, игнорируя предупреждения, играют на одном-двух сейвах, а то и вовсе на квиксейвах всю игру.

= Другие частые проблемы =

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

== Вылеты при удалении объектов из игры ==

При использовании для удаления объектов родной движковой функции '''alife():release(alife():object(id), true)''' возможен целый ворох разнообразнейших вылетов, обычно - безлоговых, что сильно затрудняет их отладку. Вот из-за чего они возникают:

1) Вылет при удалении непися или монстра, находящегося в онлайне.
Решение: с помощью alife():release '''можно удалять только мёртвые объекты'''. Поэтому если вам нужно удалить с её помощью непися или монстра, который жив и находится в онлайне, его нужно убить любым доступным методом, хотя бы нанеся ему hit() с любым запредельным уроном по вкусу.

2) Вылет при удалении оружия или артефакта.
Решение: такая проблема часто встречается в случае если объект неудачно расположен или находится в руках у непися. Для того чтобы не произошло вылета, убедитесь что объект доступен как серверный перед удалением. Вот так:

<code lua> local obj = alife():object(i)
if obj then
alife():release(obj, true)
end</code>

Эту конструкцию вообще желательно использовать всегда, когда вы так удаляете объекты.

3) Вылет при удалении аномалии.
Решение: аномалии - очень капризные при подобном с ними обращении объекты. Они влияют на своё окружение, и если рядом с ними находится непись или монстр, то удаление такой аномалии приведёт к вылету игры. Чтобы этого не произошло, аномалию надо сначала выключить функцией '''disable_anomaly''', и удалять затем ТОЛЬКО тогда, когда она не будет занята влиянием на динамический объект. Для этого нужно получить список мобов на локации, и из их нетпакетов считать идентификаторы действующих на них рестрикторов. Если ваша аномалия будет в этом списке - удалять её нельзя. Дождитесь пока она освободится.

== Вылет при открытии закладки "Контакты" в ПДА ==

Простой безлоговый вылет при открытии закладки "Контакты". Встречался во всех крупных модах, и никто не знал как его излечить. А лечится он банально - '''его причина - дублирование идентификаторов секций в XML-файле, описывающем иконки неписей для закладки "Контакты"'''. Нужно всего лишь проверить этот файл на наличие дублированных идентификаторов и удалить их. Вылет пропадёт и никогда больше не будет встречаться.

== Вылеты при вызове несуществующих функций из XML ==

В ХML-файлах, используемых для описания инфопоршенов, для многих инфопоршенов прописаны действия, которые игра вызывает при взятии этого инфопоршена. Вот так примерно:

<code xml>
<info_portion id="barman_document_have">
<action>dialogs.set_actor_prebandit1</action>
<action>bar_spawn.bandits2</action>
<action>bar_spawn.bandits3</action>
<action>bar_spawn.bandit7</action>
<action>bar_spawn.bandit8</action>
</info_portion>
</code>

Так вот, если вы допустите опечатку в названии вызываемой функции или же случайно её удалите - игра будет стабильно вылетать без лога при взятии этого инфопоршена.

== Повреждения сейвов на Радаре и других местах в модах, основанных на OGSM ==

В оригинале ОГСМ и основанных на нём модах часто встречались проблемы с сохранениями на Радаре. Эту проблему долго не удавалось победить, пока наконец благодаря помощи Маландринуса не удалось выявить её первопричину. Как выяснилось, она очень проста - гражданские зомби в моде (монстры) имели в конфиге ту же пропись вида (параметр конфига specie), что и монолитовцы и зомбированные (неписи). И там и тут было проставлено "zombie", и так оно было ещё с оригинала. Как оказалось, так делать категорически нельзя. Дело в том, что у неписей есть такой функционал, как хитовая память - в ней какое-то время хранятся ссылки на атакующие объекты. У монстров тоже есть остатки этого функционала, но он неработоспособен, и использовать его нельзя. В случае же когда монстры и неписи попадают в один вид, в ситуации когда они находятся рядом в бою, хитовая память монстров автоматически получает от неписей того же вида распространяемую внутри вида информацию об атакующих - а хранить её монстрам нельзя. Если после создания такой ситуации сохраниться - сейв будет вызывать вылет при загрузке. То есть проще говоря, если в бою с монолитовцами рядом оказывались гражданские зомби - и игрок сохранял игру - сейв этот не загружался. Чтобы предотвратить эти проблемы, вполне достаточно создать для гражданских зомби свой отдельный вид, добавив его прописи в конфиг game_relations.

== Застывания NPC после боя / лечения ранения в модах, использующих дополнительные схемы поведения ==

Во многих модах, использующих дополнительные схемы поведения часто можно заметить NPC, которые после боя застывают, прицелившись в одну точку. Аналогично часто это встречается с вылеченными от ранения NPC - они встают и замирают намертво, до тех пор пока их не выведет из этого состояния атаковавший враг. Как правило сейв/загрузка этой проблемы не решают. В ходе работы над OGSE 0.6.9.3 мне удалось выяснить причину таких проблем и успешно её устранить. Причина проблемы заключается в том, что NPC управляются не только скриптовыми схемами, но и движком, и для переключения управления между одним и другим используется скрипт ''state_mgr'' - менеджер состояний. Его директивы имеют наивысший приоритет. Аналогичный же приоритет себе как правило назначают доп. схемы поведения, используя пропись эвалуатора в ''xr_motivatior.addCommonPrecondition(action)''. В итоге при выходе из движковой боевки или при переключении на движковый алайф (это происходит после излечения ранения) доп. схемы поведения вступают с менеджером состояний в конфликт, блокируя смену состояния NPC. Для того чтобы этого не происходило, '''необходимо во всех схемах поведения, использующих принудительное назначение состояния через функцию ''state_mgr.set_state'' сделать блокировку перехвата управления менеджером состояний''', добавив соответствующие прописи в биндер. Вот таким образом, как в этом примере - тут я правил биндер схемы лечения/самолечения ''xrs_medic'':

<code lua>
function add_to_binder(object, ini, scheme, section, storage)
local operators = {}
local properties = {}

local manager = object:motivation_action_manager()

operators["medic"] = actid_medic
operators["self_medic"] = actid_self_medic

properties["medic"] = evid_medic
properties["self_medic"] = evid_self_medic

local state_mgr_to_idle_combat = xr_actions_id.state_mgr + 2 ---< Это переключение на движковую боевку, но оно тут не использовано
local state_mgr_to_idle_alife = xr_actions_id.state_mgr + 2 ---< Это переключение на движковый алайф
local state_mgr_to_idle_off = xr_actions_id.state_mgr + 3 ---< Это переключение в статичное состояние

local zombi=object:character_community()=="zombied" or object:character_community()=="trader" or
object:character_community()=="arena_enemy" or object:name()=="mil_stalker0012" or object:name()=="yantar_ecolog_general"

if zombi then
manager:add_evaluator (properties["medic"], property_evaluator_const(false))
manager:add_evaluator (properties["self_medic"], property_evaluator_const(false))
else
manager:add_evaluator (properties["medic"], evaluator_medic("medic", storage))
manager:add_evaluator (properties["self_medic"], evaluator_self_medic("self_medic", storage))
end

local action = action_medic (object,"medic", storage)
action:add_precondition(world_property(stalker_ids.property_alive, true))
action:add_precondition(world_property(xr_evaluators_id.sidor_wounded_base, false))
action:add_precondition (world_property(properties["medic"], true))
action:add_effect (world_property(properties["medic"], false))
manager:add_action (operators["medic"], action)

local action = action_self_medic (object,"self_medic", storage)
action:add_precondition(world_property(stalker_ids.property_alive, true))
action:add_precondition(world_property(stalker_ids.property_enemy,false))
action:add_precondition(world_property(xr_evaluators_id.sidor_wounded_base, false))
action:add_precondition (world_property(properties["medic"], false))
action:add_precondition (world_property(properties["self_medic"], true))
action:add_effect (world_property(properties["self_medic"], false))
manager:add_action (operators["self_medic"], action)

action = manager:action (stalker_ids.action_alife_planner)
action:add_precondition (world_property(properties["medic"], false))
action:add_precondition (world_property(properties["self_medic"], false))

action = manager:action(state_mgr_to_idle_alife)
action:add_precondition (world_property(properties["self_medic"], false)) ---< Блокируем попытки переключиться на движковый алайф пока работает самолечение

action = manager:action(state_mgr_to_idle_off)
action:add_precondition (world_property(properties["self_medic"], false)) ---< Блокируем попытки переключиться статичное состояние пока работает самолечение

end
</code>

Вставка этих директив в биндеры всех схем, которые меняют состояния принудительно устраняет конфликты, и NPC больше не виснут при смене схем.

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 11:04, 31 марта 2011 (UTC)

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

[[Категория:Скрипты]]

Как писать скрипты, не приводящие к вылетам и бою сейвов (часть 2)

2011-03-10T06:31:18Z

Kamikazze: /* Повреждения сейвов на Радаре и других местах в модах, основанных на OGSM */

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Как безопасно использовать коллбэки и таймерные события =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Использование защищённого кода в LUA =

Периодически случаются такие ситуации, когда мы можем получить вылет при проверке аргумента, и не можем его адекватно заизолировать с помощью предварительной проверки на валидность значения. Вот простой пример: когда я отлаживал '''death_callback''' неписей, я периодически сталкивался с тем, что обращение к методу '''smart_terrain_id()''' при смерти непися иногда вызывало вылет

<code>smart_terrain:1143 "attempt to index a nil value"</code>

- хотя это свойство является родным методом объекта, и отсутствовать напрочь никак не может. В итоге я пришёл к выводу, что его просто иногда не успевает отработать движок, так как вылет этот проявлялся в основном в интенсивных боях и совершенно произвольно.

Вот код, в котором происходил вылет:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- вылет происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id)
end
end
end</code>

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

'''pcall (f, arg1, ···)'''

<blockquote>Вызывает функцию f с указанными через запятую аргументами в защищённом режиме. Это означает, что любая ошибка, даже критическая, внутри вызванной функции, не передаётся наружу - вызывавшей подсистеме. Вместо этого '''pcall''' перехватывает ошибку и возвращает код статуса. Первая возвращаемая переменная это сам код, (true или false) и если всё прошло хорошо, он равен true. В этом случае '''pcall''' сразу после статуса возвращает все результаты от работы защищённой им функции. Если же в защищённой функции произошла ошибка, то '''pcall''' вернёт false и затем сообщение об ошибке. (Обратите внимание, обработка ошибки присходит БЕЗ вылета! Вместо вылета вы получите вполне адекватную строку с ошибкой, которую можно вывести в лог для последующей обработки)</blockquote>

Я настоятельно советую пользоваться этой функцией в случаях, когда из коллбэков вызываются сложные комплексные обработки, вроде обработки из менеджера вооружений AI-пака. Это позволяет предотвратить как вылеты, так и зависания обработок, и в итоге позволяет хорошо стабилизировать игру.

Возвращаясь к нашим смарттеррейнам... вот как в итоге я подавил вылет типа smart_terrain:1143 с помощью pcall:

<code lua>--- эта функция пытается проверить св-во smart_terrain_id объекта. Именно её мы вызовем в защищённом режиме.
function prot_smt_td(obj)
if IsStalker(obj) or IsMonster(obj) then
return obj:smart_terrain_id()
else
return 65535
end
end

function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if obj then
local strn_id = 65535 --- предварительно проинитим переменную, на
--- случай если у нас prot_smt_td выдаст ошибку
local result, smt_id = pcall(prot_smt_td,obj) --- вызываем prot_smt_td в защищённом режиме
--- и сразу присваиваем его вывод переменным
if result then --- если pcall выдало true
strn_id = smt_id --- тогда применяем полученное значение
end
--- если же обработка выдаст ошибку, то strn_id останется неизменным...
if strn_id ~= 65535 then
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end</code>

В других местах это делается совершенно аналогично. Подробнее об этой и многих других функция для контроля кода, незаслуженно игнорируемых большинством моддеров, можно почитать тут: http://lua-users.org/wiki/FinalizedExceptions - на английском правда, но захотите - разберётесь, там всё просто.

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

= Скрытые критические проблемы в обработке вылетов игрой =

Ведя на днях отладку, выяснил в чём проблема с периодическим боем сейвов и многими другими заморочками как в оригинале игры, так и во многих модах... дело, как выяснилось, далеко не всегда в кривых руках. Есть такая стандартная ф-ция '''abort''' - предназначенная для выкидывания из игры, если что-то пошло не так. И как оказалось, она срабатывает далеко не всегда. Выяснилось это следующим образом:

В одном из логов нашего бета-тестера я увидел '''стандартное сообщение о вылете внутри рабочего лога'''... да-да, то самое которое '''FATAL ERROR''' и дальше по тексту. При этом игра у него НЕ вылетала, это сообщение об ошибке мы обнаружили позже, по случайности. Я заподозрил, что что-то не в порядке, и вставил внутрь этой ф-ции контрольную метку, кидавшую в консоль сообщение, в котором содержался паттерн сообщения об ошибке и само сообщение. Так вот, оказалось, что эта самая функция '''abort''' вызывается в игре с завидным постоянством (вы удивитесь насколько часто), когда возникают исключения в схемах логики, звука и т.д., но игра от этого вылетает на рабочий стол '''максимум только 3 раза из 10 вызовов'''. Вылет НЕ происходит обычно, когда функции передан паттерн ошибки, а остальные параметры пустые, такое бывает, и частенько. И если не сделать внутри этой функции особой метки для вывода в лог, как сделал это я, её вызовы проходят совершенно незаметно, и '''игра после критических ошибок продолжается как ни в чём ни бывало.''' А приводит это вот к чему... Внутри '''xr_logic''' в процедуре записи пстора (хранилища логики и флагов) неписей есть вызовы этого самого аборта в случае если на запись в пстор передана некорректная величина. Ну а так как аборт периодически вообще не срабатывает, то часто попадается ситуация, что неписям в пстор пишется полный ахтунг: куски кода из ОЗУ, всякая муть из лтх-ов, куски аллспавна, всё что угодно. Происходит это оттого, что кодер, писавший эту функцию ('''xr_logic.pstor_store(obj, varname, val)'''), явно и думать не думал что '''abort''' может не сработать. У него запись в пстор стояла после проверки, а не внутри неё (very bad idea), и если abort не срабатывал, игра писала в пстор мусор совершенно спокойно и незаметно для игрока. Потом вся эта хрень попадала прямо в сейвы. Вот проблемный код для наглядности:

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv) --- вот тут мы должны если что вылететь
end
db.storage[npc_id].pstor[varname] = val -- а если не вылетели, всё, получим запись в пстор левой мути
end</code>

Разумеется игра этим пстором в итоге давится, и сейвы сделанные после такой милой записи практически лопаются. Результат - "битые" (на самом деле подлежат реанимации) сейвы. Происходит это потому, что игра из сейва грузит неписям псторы сплошным чтением по словам, пока они не закончатся. В случае же если в псторе обнаруживается записанный ранее мусор, то обработка либо вылетает сразу, либо наглухо виснет, пытаясь запихать эдак с миллион слов в пстор особо отличившегося непися. Как вам например непись с размером пстора в 1697451 слова? В результате попытки его обработать игра просто на стадии синхронизации выжрала всю доступную ОЗУ и повисла.

Решение этой проблемы оказалось достатоно простым: во-первых я предположил максимальный размер полезной части пстора неписей в 20 слов r_u32() (пока ориентировочно, я ещё уточняю эту величину), и соответственно сделал остановку цикла загрузки пстора для неписей через 20 итераций. Там же, где в цикле стояла проверка на валидность записываемых данных (кстати тоже с вылетом в случае провала проверки), я сделал так, что если параметр не относится к валидному типу данных, то запись параметра в пстор не производится совсем. Это необходимо для того, чтобы если вдруг в сейве обнаружится мусор, то он был бы просто отброшен обработкой. Практика показала, что в итоге такие неписи вполне адекватны и в дальнейшем никаких проблем не вызывают, так как начало их пстора, с нормальными данными, обычно не повреждается - мусор дописывается после них, а не вместо них.

Ну и во-вторых модифицировал запись параметров в пстор, просто убрав запись под основание if-else так, чтобы если параметр неверен, он не записывался совсем. Теперь кстати, очень интересно, сохранились ли те же заморочки с ф-цией '''abort''' в Чистом Небе, и если да, то останутся ли в Зове Припяти?

------------

== Необходимые для стабилизации игры правки в модулях ==

'''Эта правка предотвращает запись в пстор если не сработал аборт:'''

''xr_logic.script''

'''Было:'''

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv)
end
db.storage[npc_id].pstor[varname] = val
end</code>

'''Стало:'''

<code lua>function pstor_store(obj, varname, val)
if not obj then return end
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
dgblog("xr_logic: pstor_store: not registered type encountered - write in pstor_store cancelled")
-- abort убран, так как один хрен не работает. Пусть тогда хотя бы в лог что-то валится.
else
db.storage[npc_id].pstor[varname] = val
-- вот так и только так. Если значение не валидно, ничего не происходит.
end
end</code>

'''А эта правка выкинет из пстора весь мусор при загрузке сейва, если он как-то в него попал'''

'''Было:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
abort("xr_logic: pstor_load_all: not registered type N %d encountered", tn)
end
printf("_bp: pstor_load_all: loaded [%s]='%s'", varname, utils.to_str(pstor[varname]))
end
end</code>

'''Стало:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
if tonumber(ctr) > 20 and tostring(obj:name()) ~= "single_player" and npc_id ~= db.actor:id() then
-- максимум 20 итераций - это число ещё уточняется, возможно понадобится больше
-- если у вас в пстор что-то свое пишется, ориентируйтесь на свои значения
-- и обязательно убираем из проверки актора - у него очень толстый пстор, и к тому же
-- если уж поврежденным будет его пстор, то тут точно уже ничего не поможет
dgblog("ОБНАРУЖЕН ОБЪЕКТ С ПОВРЕЖДЕННЫМ PSTOR: "..tostring(obj:name())..
" БУДЕТ ПРОИЗВЕДЕНА ПОПЫТКА ВОССТАНОВЛЕНИЯ")
ctr = 20
end
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
-- не надо пытаться вылетать - просто не пишем поврежденные данные
-- при этом обязательно удалять саму переменную - в результате записи
-- мусора в пстор одно только ее название может повесить загрузку
pstor[varname] = nil
end
end
end</code>

Эти примеры приведены для чистой игры. Единственное в чем не уверен пока, это в том, что максимум полезного размера - 20 слов. Возможно нужно выделить больше, это надо будет проверить ещё экспериментальным путем...

Кроме этого, советую ещё внутрь ф-ции abort вставить отладочные метки, чтобы точно знать когда она вызывалась. Настоятельно советую сделать это даже если вы матёрый моддер со стажем - гарантирую, будете неприятно удивлены.

Я это сделал вот так:

''_g.script''

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
end</code>

По поводу частичной неработоспособности ф-ции '''abort''' я беседовал с Колмогором, и он пришёл к выводу, что видимо вылет игры должен был бы производиться при обработке функции '''printf("%s")''' - ей тут передаётся заведомо отсутствующий оператор и она по уму должна бы сразу крашить игру. Однако в релизе функция printf фактически не работает(она реализована в _g.script через вырезанную функцию log). В результате игра не крашится. Но что поделать, в итоге мне пришлось модифицировать его таким образом, чтобы вылет при его срабатывании был гарантирован:

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
local crash
local ooops = 1/crash
end</code>

Вылет происходит при попытке произвести арифметическую операцию с неинициализированной переменной crash.

== Лечение зависаний алайфа при смерти персонажей ==

Недавно, отлаживая проблемы с зависанием алайфа, мне удалось найти причину этого периодически во всех модах всплывающего сбоя, приводящего к порче сейвов и сильно мешающего нормально играть. Сбой этот возникает при смерти некоторых NPC, обычно квестовых. В частности в моём случае изолировать и отладить это зависание удалось на Юрике, новичке со Свалке, учавствующем в сцене с гоп-стопом. Причина оказалась в обработке посмертной отрегистрации NPC из гулагов, причём сбой там был настоящей матрёшкой, составной из нескольких частей. Правок в итоге было совсем немного, но чтобы сделать их мне пришлось несколько часов распутывать клубок из кросс-вызовов между скриптами smart_terrain и xr_gulag. Итак, начнём с самого начала. Работая над OGSE 069 и 0691 я периодически сталкивался с зависаниями и вылетами в посмертных обработках неписей. Один из таких вылетов - всем хорошо знакомый вылет:

<code>smart_terrain:1143 "attempt to index a nil value"</code>

Происходящий в функции '''smart_terrain.on_death( obj_id )''' - я тогда его заблокировал вызовом его внутри безопасного кода функцией '''pcall''', однако, как теперь выяснилось, этого оказалось недостаточно - баг тут состоит из нескольких частей, и этот вылет указывает только на одну из них. Вот исходный код:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- первый вылет/зависнаие алайфа происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id) -- а вот в этой обработке происходит зависание алайфа. Она очень комплексная, и её сложно распутывать.
end
end
end</code>

Во-первых выяснилось, что изредка вызов '''obj:smart_terrain_id()''' вызывает зависание алайфа даже когда он производится изнутри защищённого кода. Тогда я решил избавиться от использования этой функции в данном месте совсем. После нескольких экспериментов выяснилось, что самым простым, быстрым и вылетобезопасным способом будет считать нетпакет существа в таблицу и выудить идентификатор смарттеррейна из неё. Для этого можно написать свою обработку, однако я, как весьма ленивый программист, не склонен изобретать велосипеды, поэтому я воспользовался уже проверенной у нас и активно используемой в OGSE библиотекой функций для работы с нетпакетами '''m_net_utils''' Артоса. Кроме того, я сразу сделал более безопасным вызов обработки на отрегистрацию в гулагах. Вот, собственно, что в итоге получилось:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if (obj and obj.smart_terrain_id) then
local strn_id = 65535 -- значение по умолчанию

local t = nil -- сюда запихнём табличку из пакета
if IsStalker(obj) then t = m_net_utils.get_stalker_data(obj) elseif IsMonster(obj) then t = m_net_utils.get_monster_data(obj) end
-- вызываем парсинг пакета для неписей и монстров отдельно

-- print_table_inlog(t)
if t.smtrid then
strn_id = tonumber(t.smtrid) -- получаем идентификатор смарта, если его нету даже в пакете, хрен с ним, будет 65535
end

if strn_id ~= 65535 then -- если сняли идентификатор, попробуем отрегать...
local gulag = sim:object(strn_id)
if gulag and gulag.gulag then -- ...но сначала выясним если вообще такой гулаг и инициализирован ли он
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end
end</code>

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

<code>Description: xr_gulag:1035 value not found ObjectJobPathName[obj_id]</code>

'''Вернёшь строки на место, перестроишь текст - работает снова. Совершенная чертовщина, шаманил я над этой функцией около получаса, перестраивая текст таким образом чтобы игра нормально запускалась.''' Имейте это в виду когда в неё полезете и если что не пугайтесь если игра начнёт так вылетать - в этом случае пошаманьте немного над ней, меняя её форматирование. О причинах такого поведения я не могу даже догадываться - то ли движок её вызывает по смещению внутри файла вручную, то ли это какой-то баг Lua-парсера, но факт фактом.

Итак, теперь проблема с получением идентификатора смарта разрешилась, однако алайф всё равно зависал! Простая трассировка показала, что теперь зависание происходило внутри обработки

<code lua>sim:object(strn_id).gulag:clear_dead(obj_id)</code>

И мне пришлость распутывать её по частям, доискиваясь до причины. Обработка честно говоря мерзкая, размазана по smart_terrain и xr_gulag, при этом взаимные вызовы идут не менее десятка раз, в следующем стиле: ф-ция в смарте вызывает ф-цию в гулаге, которая вызывает фцию в смарте, которая обрабатывает параметр фцией в гулаге, который передётся ф-цией в логике, которая получает её из смарта. Нечто подобное. Опуская все нецензурные выражения, употребленные мной при трассировке, я лучше расскажу что собственно вышло в итоге. А в итоге я вышел вот на этот код в xr_gulag, именно в нём при отрегистрации некоторых мёртвых неписей происходит зависание алайфа:

<code lua>-- освободить объект от работы и переинициализировать логику.
-- если сталкер в онлайне и начал работу, то сбросить его схему поведения
-- как будто он только что загрузился
function gulag:free_obj_and_reinit( obj_id )
self:free_obj(obj_id)

local t = self.Object[obj_id]
if t ~= nil and t ~= true and self.Object_begin_job[obj_id] then
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) ) -- вот эта обработка вешает алайф
end
end</code>

Я, честно говоря, ни разу не понимаю, на кой чёрт нужно переконфигурировать схемы логики и выбирать из них активную '''трупу, который лежит себе спокойно и никого не трогает.''' Может быть в это есть некий высший смысл, или это было продиктовано неким аккуратизмом, однако одно я могу сказать однозначно - подобная переинициализация у некоторых трупов неписей приводит к глухому зависанию алайфа. При этом если для трупов эту обработку заблокировать, то трупы разрегистрируются вполне нормально и спокойно лежат с нетронутой логикой, не вызывая никаких проблем. Итоговый код после правок выглядит вот так:

<code lua>-- освободить объект от работы и переинициализировать логику.
-- если сталкер в онлайне и начал работу, то сбросить его схему поведения
-- как будто он только что загрузился
function gulag:free_obj_and_reinit( obj_id )
self:free_obj(obj_id)
local t = self.Object[obj_id]
if t ~= nil and t ~= true and self.Object_begin_job[obj_id] then
if check_game() then -- тут проверяется, запущена ли игра, если ли актор и жив ли он. Если да, делаем по новому.
local s_obj = alife():object(obj_id) -- проверим есть ли у цели разрегистрации валидный серверный объект
if s_obj and (IsStalker(s_obj) or IsMonster(s_obj)) and s_obj:alive() then -- если есть, он жив и сталкер или монстр
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) ) -- только тогда инициализируем логику
end
else -- а если игра не запущена, то как раньше. Это нужно для того, чтобы обработка запуска игры нормально работала.
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) )
end
end
end

-- Проверка, запущена ли игра
function check_game()
if level.present() and (db.actor ~= nil) and db.actor:alive() then
return true
end
return false
end
</code>

После этих поправок зависания алайфа при смерти неписей удалось побороть окончательно. Решение с отрезанием реинита логики для трупов несколько грубовато, но честно говоря, у меня нет ни малейшего желания трассировать и разбирать на части функцию xr_logic.initialize_obj, выясняя, чем же ей так данный конкретный труп не приглянулся. Если хотите - займитесь, найдёте причину - дополните данную статью. Я же успокоился на том, что заблокировал баг, периодически убивающий людям игру, так как многие пользователи, игнорируя предупреждения, играют на одном-двух сейвах, а то и вовсе на квиксейвах всю игру.

= Другие частые проблемы =

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

== Вылеты при удалении объектов из игры ==

При использовании для удаления объектов родной движковой функции '''alife():release(alife():object(id), true)''' возможен целый ворох разнообразнейших вылетов, обычно - безлоговых, что сильно затрудняет их отладку. Вот из-за чего они возникают:

1) Вылет при удалении непися или монстра, находящегося в онлайне.
Решение: с помощью alife():release '''можно удалять только мёртвые объекты'''. Поэтому если вам нужно удалить с её помощью непися или монстра, который жив и находится в онлайне, его нужно убить любым доступным методом, хотя бы нанеся ему hit() с любым запредельным уроном по вкусу.

2) Вылет при удалении оружия или артефакта.
Решение: такая проблема часто встречается в случае если объект неудачно расположен или находится в руках у непися. Для того чтобы не произошло вылета, убедитесь что объект доступен как серверный перед удалением. Вот так:

<code lua> local obj = alife():object(i)
if obj then
alife():release(obj, true)
end</code>

Эту конструкцию вообще желательно использовать всегда, когда вы так удаляете объекты.

3) Вылет при удалении аномалии.
Решение: аномалии - очень капризные при подобном с ними обращении объекты. Они влияют на своё окружение, и если рядом с ними находится непись или монстр, то удаление такой аномалии приведёт к вылету игры. Чтобы этого не произошло, аномалию надо сначала выключить функцией '''disable_anomaly''', и удалять затем ТОЛЬКО тогда, когда она не будет занята влиянием на динамический объект. Для этого нужно получить список мобов на локации, и из их нетпакетов считать идентификаторы действующих на них рестрикторов. Если ваша аномалия будет в этом списке - удалять её нельзя. Дождитесь пока она освободится.

== Вылет при открытии закладки "Контакты" в ПДА ==

Простой безлоговый вылет при открытии закладки "Контакты". Встречался во всех крупных модах, и никто не знал как его излечить. А лечится он банально - '''его причина - дублирование идентификаторов секций в XML-файле, описывающем иконки неписей для закладки "Контакты"'''. Нужно всего лишь проверить этот файл на наличие дублированных идентификаторов и удалить их. Вылет пропадёт и никогда больше не будет встречаться.

== Вылеты при вызове несуществующих функций из XML ==

В ХML-файлах, используемых для описания инфопоршенов, для многих инфопоршенов прописаны действия, которые игра вызывает при взятии этого инфопоршена. Вот так примерно:

<code xml>
<info_portion id="barman_document_have">
<action>dialogs.set_actor_prebandit1</action>
<action>bar_spawn.bandits2</action>
<action>bar_spawn.bandits3</action>
<action>bar_spawn.bandit7</action>
<action>bar_spawn.bandit8</action>
</info_portion>
</code>

Так вот, если вы допустите опечатку в названии вызываемой функции или же случайно её удалите - игра будет стабильно вылетать без лога при взятии этого инфопоршена.

== Повреждения сейвов на Радаре и других местах в модах, основанных на OGSM ==

В оригинале ОГСМ и основанных на нём модах часто встречались проблемы с сохранениями на Радаре. Эту проблему долго не удавалось победить, пока наконец благодаря помощи Маландринуса не удалось выявить её первопричину. Как выяснилось, она очень проста - гражданские зомби в моде (монстры) имели в конфиге ту же пропись вида (параметр конфига specie), что и монолитовцы и зомбированные (неписи). И там и тут было проставлено "zombie", и так оно было ещё с оригинала. Как оказалось, так делать категорически нельзя. Дело в том, что у неписей есть такой функционал, как хитовая память - в ней какое-то время хранятся ссылки на атакующие объекты. У монстров тоже есть остатки этого функционала, но он неработоспособен, и использовать его нельзя. В случае же когда монстры и неписи попадают в один вид, в ситуации когда они находятся рядом в бою, хитовая память монстров автоматически получает от неписей того же вида распространяемую внутри вида информацию об атакующих - а хранить её монстрам нельзя. Если после создания такой ситуации сохраниться - сейв будет вызывать вылет при загрузке. То есть проще говоря, если в бою с монолитовцами рядом оказывались гражданские зомби - и игрок сохранял игру - сейв этот не загружался. Чтобы предотвратить эти проблемы, вполне достаточно создать для гражданских зомби свой отдельный вид, добавив его прописи в конфиг game_relations.

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 11:04, 3 сентября 2009 (UTC)

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

[[Категория:Скрипты]]

Как писать скрипты, не приводящие к вылетам и бою сейвов (часть 2)

2011-03-10T06:30:47Z

Kamikazze: Добавлена информация о предотвращении боя сейвов на Радаре

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Как безопасно использовать коллбэки и таймерные события =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Использование защищённого кода в LUA =

Периодически случаются такие ситуации, когда мы можем получить вылет при проверке аргумента, и не можем его адекватно заизолировать с помощью предварительной проверки на валидность значения. Вот простой пример: когда я отлаживал '''death_callback''' неписей, я периодически сталкивался с тем, что обращение к методу '''smart_terrain_id()''' при смерти непися иногда вызывало вылет

<code>smart_terrain:1143 "attempt to index a nil value"</code>

- хотя это свойство является родным методом объекта, и отсутствовать напрочь никак не может. В итоге я пришёл к выводу, что его просто иногда не успевает отработать движок, так как вылет этот проявлялся в основном в интенсивных боях и совершенно произвольно.

Вот код, в котором происходил вылет:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- вылет происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id)
end
end
end</code>

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

'''pcall (f, arg1, ···)'''

<blockquote>Вызывает функцию f с указанными через запятую аргументами в защищённом режиме. Это означает, что любая ошибка, даже критическая, внутри вызванной функции, не передаётся наружу - вызывавшей подсистеме. Вместо этого '''pcall''' перехватывает ошибку и возвращает код статуса. Первая возвращаемая переменная это сам код, (true или false) и если всё прошло хорошо, он равен true. В этом случае '''pcall''' сразу после статуса возвращает все результаты от работы защищённой им функции. Если же в защищённой функции произошла ошибка, то '''pcall''' вернёт false и затем сообщение об ошибке. (Обратите внимание, обработка ошибки присходит БЕЗ вылета! Вместо вылета вы получите вполне адекватную строку с ошибкой, которую можно вывести в лог для последующей обработки)</blockquote>

Я настоятельно советую пользоваться этой функцией в случаях, когда из коллбэков вызываются сложные комплексные обработки, вроде обработки из менеджера вооружений AI-пака. Это позволяет предотвратить как вылеты, так и зависания обработок, и в итоге позволяет хорошо стабилизировать игру.

Возвращаясь к нашим смарттеррейнам... вот как в итоге я подавил вылет типа smart_terrain:1143 с помощью pcall:

<code lua>--- эта функция пытается проверить св-во smart_terrain_id объекта. Именно её мы вызовем в защищённом режиме.
function prot_smt_td(obj)
if IsStalker(obj) or IsMonster(obj) then
return obj:smart_terrain_id()
else
return 65535
end
end

function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if obj then
local strn_id = 65535 --- предварительно проинитим переменную, на
--- случай если у нас prot_smt_td выдаст ошибку
local result, smt_id = pcall(prot_smt_td,obj) --- вызываем prot_smt_td в защищённом режиме
--- и сразу присваиваем его вывод переменным
if result then --- если pcall выдало true
strn_id = smt_id --- тогда применяем полученное значение
end
--- если же обработка выдаст ошибку, то strn_id останется неизменным...
if strn_id ~= 65535 then
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end</code>

В других местах это делается совершенно аналогично. Подробнее об этой и многих других функция для контроля кода, незаслуженно игнорируемых большинством моддеров, можно почитать тут: http://lua-users.org/wiki/FinalizedExceptions - на английском правда, но захотите - разберётесь, там всё просто.

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

= Скрытые критические проблемы в обработке вылетов игрой =

Ведя на днях отладку, выяснил в чём проблема с периодическим боем сейвов и многими другими заморочками как в оригинале игры, так и во многих модах... дело, как выяснилось, далеко не всегда в кривых руках. Есть такая стандартная ф-ция '''abort''' - предназначенная для выкидывания из игры, если что-то пошло не так. И как оказалось, она срабатывает далеко не всегда. Выяснилось это следующим образом:

В одном из логов нашего бета-тестера я увидел '''стандартное сообщение о вылете внутри рабочего лога'''... да-да, то самое которое '''FATAL ERROR''' и дальше по тексту. При этом игра у него НЕ вылетала, это сообщение об ошибке мы обнаружили позже, по случайности. Я заподозрил, что что-то не в порядке, и вставил внутрь этой ф-ции контрольную метку, кидавшую в консоль сообщение, в котором содержался паттерн сообщения об ошибке и само сообщение. Так вот, оказалось, что эта самая функция '''abort''' вызывается в игре с завидным постоянством (вы удивитесь насколько часто), когда возникают исключения в схемах логики, звука и т.д., но игра от этого вылетает на рабочий стол '''максимум только 3 раза из 10 вызовов'''. Вылет НЕ происходит обычно, когда функции передан паттерн ошибки, а остальные параметры пустые, такое бывает, и частенько. И если не сделать внутри этой функции особой метки для вывода в лог, как сделал это я, её вызовы проходят совершенно незаметно, и '''игра после критических ошибок продолжается как ни в чём ни бывало.''' А приводит это вот к чему... Внутри '''xr_logic''' в процедуре записи пстора (хранилища логики и флагов) неписей есть вызовы этого самого аборта в случае если на запись в пстор передана некорректная величина. Ну а так как аборт периодически вообще не срабатывает, то часто попадается ситуация, что неписям в пстор пишется полный ахтунг: куски кода из ОЗУ, всякая муть из лтх-ов, куски аллспавна, всё что угодно. Происходит это оттого, что кодер, писавший эту функцию ('''xr_logic.pstor_store(obj, varname, val)'''), явно и думать не думал что '''abort''' может не сработать. У него запись в пстор стояла после проверки, а не внутри неё (very bad idea), и если abort не срабатывал, игра писала в пстор мусор совершенно спокойно и незаметно для игрока. Потом вся эта хрень попадала прямо в сейвы. Вот проблемный код для наглядности:

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv) --- вот тут мы должны если что вылететь
end
db.storage[npc_id].pstor[varname] = val -- а если не вылетели, всё, получим запись в пстор левой мути
end</code>

Разумеется игра этим пстором в итоге давится, и сейвы сделанные после такой милой записи практически лопаются. Результат - "битые" (на самом деле подлежат реанимации) сейвы. Происходит это потому, что игра из сейва грузит неписям псторы сплошным чтением по словам, пока они не закончатся. В случае же если в псторе обнаруживается записанный ранее мусор, то обработка либо вылетает сразу, либо наглухо виснет, пытаясь запихать эдак с миллион слов в пстор особо отличившегося непися. Как вам например непись с размером пстора в 1697451 слова? В результате попытки его обработать игра просто на стадии синхронизации выжрала всю доступную ОЗУ и повисла.

Решение этой проблемы оказалось достатоно простым: во-первых я предположил максимальный размер полезной части пстора неписей в 20 слов r_u32() (пока ориентировочно, я ещё уточняю эту величину), и соответственно сделал остановку цикла загрузки пстора для неписей через 20 итераций. Там же, где в цикле стояла проверка на валидность записываемых данных (кстати тоже с вылетом в случае провала проверки), я сделал так, что если параметр не относится к валидному типу данных, то запись параметра в пстор не производится совсем. Это необходимо для того, чтобы если вдруг в сейве обнаружится мусор, то он был бы просто отброшен обработкой. Практика показала, что в итоге такие неписи вполне адекватны и в дальнейшем никаких проблем не вызывают, так как начало их пстора, с нормальными данными, обычно не повреждается - мусор дописывается после них, а не вместо них.

Ну и во-вторых модифицировал запись параметров в пстор, просто убрав запись под основание if-else так, чтобы если параметр неверен, он не записывался совсем. Теперь кстати, очень интересно, сохранились ли те же заморочки с ф-цией '''abort''' в Чистом Небе, и если да, то останутся ли в Зове Припяти?

------------

== Необходимые для стабилизации игры правки в модулях ==

'''Эта правка предотвращает запись в пстор если не сработал аборт:'''

''xr_logic.script''

'''Было:'''

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv)
end
db.storage[npc_id].pstor[varname] = val
end</code>

'''Стало:'''

<code lua>function pstor_store(obj, varname, val)
if not obj then return end
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
dgblog("xr_logic: pstor_store: not registered type encountered - write in pstor_store cancelled")
-- abort убран, так как один хрен не работает. Пусть тогда хотя бы в лог что-то валится.
else
db.storage[npc_id].pstor[varname] = val
-- вот так и только так. Если значение не валидно, ничего не происходит.
end
end</code>

'''А эта правка выкинет из пстора весь мусор при загрузке сейва, если он как-то в него попал'''

'''Было:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
abort("xr_logic: pstor_load_all: not registered type N %d encountered", tn)
end
printf("_bp: pstor_load_all: loaded [%s]='%s'", varname, utils.to_str(pstor[varname]))
end
end</code>

'''Стало:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
if tonumber(ctr) > 20 and tostring(obj:name()) ~= "single_player" and npc_id ~= db.actor:id() then
-- максимум 20 итераций - это число ещё уточняется, возможно понадобится больше
-- если у вас в пстор что-то свое пишется, ориентируйтесь на свои значения
-- и обязательно убираем из проверки актора - у него очень толстый пстор, и к тому же
-- если уж поврежденным будет его пстор, то тут точно уже ничего не поможет
dgblog("ОБНАРУЖЕН ОБЪЕКТ С ПОВРЕЖДЕННЫМ PSTOR: "..tostring(obj:name())..
" БУДЕТ ПРОИЗВЕДЕНА ПОПЫТКА ВОССТАНОВЛЕНИЯ")
ctr = 20
end
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
-- не надо пытаться вылетать - просто не пишем поврежденные данные
-- при этом обязательно удалять саму переменную - в результате записи
-- мусора в пстор одно только ее название может повесить загрузку
pstor[varname] = nil
end
end
end</code>

Эти примеры приведены для чистой игры. Единственное в чем не уверен пока, это в том, что максимум полезного размера - 20 слов. Возможно нужно выделить больше, это надо будет проверить ещё экспериментальным путем...

Кроме этого, советую ещё внутрь ф-ции abort вставить отладочные метки, чтобы точно знать когда она вызывалась. Настоятельно советую сделать это даже если вы матёрый моддер со стажем - гарантирую, будете неприятно удивлены.

Я это сделал вот так:

''_g.script''

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
end</code>

По поводу частичной неработоспособности ф-ции '''abort''' я беседовал с Колмогором, и он пришёл к выводу, что видимо вылет игры должен был бы производиться при обработке функции '''printf("%s")''' - ей тут передаётся заведомо отсутствующий оператор и она по уму должна бы сразу крашить игру. Однако в релизе функция printf фактически не работает(она реализована в _g.script через вырезанную функцию log). В результате игра не крашится. Но что поделать, в итоге мне пришлось модифицировать его таким образом, чтобы вылет при его срабатывании был гарантирован:

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
local crash
local ooops = 1/crash
end</code>

Вылет происходит при попытке произвести арифметическую операцию с неинициализированной переменной crash.

== Лечение зависаний алайфа при смерти персонажей ==

Недавно, отлаживая проблемы с зависанием алайфа, мне удалось найти причину этого периодически во всех модах всплывающего сбоя, приводящего к порче сейвов и сильно мешающего нормально играть. Сбой этот возникает при смерти некоторых NPC, обычно квестовых. В частности в моём случае изолировать и отладить это зависание удалось на Юрике, новичке со Свалке, учавствующем в сцене с гоп-стопом. Причина оказалась в обработке посмертной отрегистрации NPC из гулагов, причём сбой там был настоящей матрёшкой, составной из нескольких частей. Правок в итоге было совсем немного, но чтобы сделать их мне пришлось несколько часов распутывать клубок из кросс-вызовов между скриптами smart_terrain и xr_gulag. Итак, начнём с самого начала. Работая над OGSE 069 и 0691 я периодически сталкивался с зависаниями и вылетами в посмертных обработках неписей. Один из таких вылетов - всем хорошо знакомый вылет:

<code>smart_terrain:1143 "attempt to index a nil value"</code>

Происходящий в функции '''smart_terrain.on_death( obj_id )''' - я тогда его заблокировал вызовом его внутри безопасного кода функцией '''pcall''', однако, как теперь выяснилось, этого оказалось недостаточно - баг тут состоит из нескольких частей, и этот вылет указывает только на одну из них. Вот исходный код:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- первый вылет/зависнаие алайфа происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id) -- а вот в этой обработке происходит зависание алайфа. Она очень комплексная, и её сложно распутывать.
end
end
end</code>

Во-первых выяснилось, что изредка вызов '''obj:smart_terrain_id()''' вызывает зависание алайфа даже когда он производится изнутри защищённого кода. Тогда я решил избавиться от использования этой функции в данном месте совсем. После нескольких экспериментов выяснилось, что самым простым, быстрым и вылетобезопасным способом будет считать нетпакет существа в таблицу и выудить идентификатор смарттеррейна из неё. Для этого можно написать свою обработку, однако я, как весьма ленивый программист, не склонен изобретать велосипеды, поэтому я воспользовался уже проверенной у нас и активно используемой в OGSE библиотекой функций для работы с нетпакетами '''m_net_utils''' Артоса. Кроме того, я сразу сделал более безопасным вызов обработки на отрегистрацию в гулагах. Вот, собственно, что в итоге получилось:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if (obj and obj.smart_terrain_id) then
local strn_id = 65535 -- значение по умолчанию

local t = nil -- сюда запихнём табличку из пакета
if IsStalker(obj) then t = m_net_utils.get_stalker_data(obj) elseif IsMonster(obj) then t = m_net_utils.get_monster_data(obj) end
-- вызываем парсинг пакета для неписей и монстров отдельно

-- print_table_inlog(t)
if t.smtrid then
strn_id = tonumber(t.smtrid) -- получаем идентификатор смарта, если его нету даже в пакете, хрен с ним, будет 65535
end

if strn_id ~= 65535 then -- если сняли идентификатор, попробуем отрегать...
local gulag = sim:object(strn_id)
if gulag and gulag.gulag then -- ...но сначала выясним если вообще такой гулаг и инициализирован ли он
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end
end</code>

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

<code>Description: xr_gulag:1035 value not found ObjectJobPathName[obj_id]</code>

'''Вернёшь строки на место, перестроишь текст - работает снова. Совершенная чертовщина, шаманил я над этой функцией около получаса, перестраивая текст таким образом чтобы игра нормально запускалась.''' Имейте это в виду когда в неё полезете и если что не пугайтесь если игра начнёт так вылетать - в этом случае пошаманьте немного над ней, меняя её форматирование. О причинах такого поведения я не могу даже догадываться - то ли движок её вызывает по смещению внутри файла вручную, то ли это какой-то баг Lua-парсера, но факт фактом.

Итак, теперь проблема с получением идентификатора смарта разрешилась, однако алайф всё равно зависал! Простая трассировка показала, что теперь зависание происходило внутри обработки

<code lua>sim:object(strn_id).gulag:clear_dead(obj_id)</code>

И мне пришлость распутывать её по частям, доискиваясь до причины. Обработка честно говоря мерзкая, размазана по smart_terrain и xr_gulag, при этом взаимные вызовы идут не менее десятка раз, в следующем стиле: ф-ция в смарте вызывает ф-цию в гулаге, которая вызывает фцию в смарте, которая обрабатывает параметр фцией в гулаге, который передётся ф-цией в логике, которая получает её из смарта. Нечто подобное. Опуская все нецензурные выражения, употребленные мной при трассировке, я лучше расскажу что собственно вышло в итоге. А в итоге я вышел вот на этот код в xr_gulag, именно в нём при отрегистрации некоторых мёртвых неписей происходит зависание алайфа:

<code lua>-- освободить объект от работы и переинициализировать логику.
-- если сталкер в онлайне и начал работу, то сбросить его схему поведения
-- как будто он только что загрузился
function gulag:free_obj_and_reinit( obj_id )
self:free_obj(obj_id)

local t = self.Object[obj_id]
if t ~= nil and t ~= true and self.Object_begin_job[obj_id] then
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) ) -- вот эта обработка вешает алайф
end
end</code>

Я, честно говоря, ни разу не понимаю, на кой чёрт нужно переконфигурировать схемы логики и выбирать из них активную '''трупу, который лежит себе спокойно и никого не трогает.''' Может быть в это есть некий высший смысл, или это было продиктовано неким аккуратизмом, однако одно я могу сказать однозначно - подобная переинициализация у некоторых трупов неписей приводит к глухому зависанию алайфа. При этом если для трупов эту обработку заблокировать, то трупы разрегистрируются вполне нормально и спокойно лежат с нетронутой логикой, не вызывая никаких проблем. Итоговый код после правок выглядит вот так:

<code lua>-- освободить объект от работы и переинициализировать логику.
-- если сталкер в онлайне и начал работу, то сбросить его схему поведения
-- как будто он только что загрузился
function gulag:free_obj_and_reinit( obj_id )
self:free_obj(obj_id)
local t = self.Object[obj_id]
if t ~= nil and t ~= true and self.Object_begin_job[obj_id] then
if check_game() then -- тут проверяется, запущена ли игра, если ли актор и жив ли он. Если да, делаем по новому.
local s_obj = alife():object(obj_id) -- проверим есть ли у цели разрегистрации валидный серверный объект
if s_obj and (IsStalker(s_obj) or IsMonster(s_obj)) and s_obj:alive() then -- если есть, он жив и сталкер или монстр
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) ) -- только тогда инициализируем логику
end
else -- а если игра не запущена, то как раньше. Это нужно для того, чтобы обработка запуска игры нормально работала.
xr_logic.initialize_obj( t, nil, false, db.actor, self:get_stype( obj_id ) )
end
end
end

-- Проверка, запущена ли игра
function check_game()
if level.present() and (db.actor ~= nil) and db.actor:alive() then
return true
end
return false
end
</code>

После этих поправок зависания алайфа при смерти неписей удалось побороть окончательно. Решение с отрезанием реинита логики для трупов несколько грубовато, но честно говоря, у меня нет ни малейшего желания трассировать и разбирать на части функцию xr_logic.initialize_obj, выясняя, чем же ей так данный конкретный труп не приглянулся. Если хотите - займитесь, найдёте причину - дополните данную статью. Я же успокоился на том, что заблокировал баг, периодически убивающий людям игру, так как многие пользователи, игнорируя предупреждения, играют на одном-двух сейвах, а то и вовсе на квиксейвах всю игру.

= Другие частые проблемы =

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

== Вылеты при удалении объектов из игры ==

При использовании для удаления объектов родной движковой функции '''alife():release(alife():object(id), true)''' возможен целый ворох разнообразнейших вылетов, обычно - безлоговых, что сильно затрудняет их отладку. Вот из-за чего они возникают:

1) Вылет при удалении непися или монстра, находящегося в онлайне.
Решение: с помощью alife():release '''можно удалять только мёртвые объекты'''. Поэтому если вам нужно удалить с её помощью непися или монстра, который жив и находится в онлайне, его нужно убить любым доступным методом, хотя бы нанеся ему hit() с любым запредельным уроном по вкусу.

2) Вылет при удалении оружия или артефакта.
Решение: такая проблема часто встречается в случае если объект неудачно расположен или находится в руках у непися. Для того чтобы не произошло вылета, убедитесь что объект доступен как серверный перед удалением. Вот так:

<code lua> local obj = alife():object(i)
if obj then
alife():release(obj, true)
end</code>

Эту конструкцию вообще желательно использовать всегда, когда вы так удаляете объекты.

3) Вылет при удалении аномалии.
Решение: аномалии - очень капризные при подобном с ними обращении объекты. Они влияют на своё окружение, и если рядом с ними находится непись или монстр, то удаление такой аномалии приведёт к вылету игры. Чтобы этого не произошло, аномалию надо сначала выключить функцией '''disable_anomaly''', и удалять затем ТОЛЬКО тогда, когда она не будет занята влиянием на динамический объект. Для этого нужно получить список мобов на локации, и из их нетпакетов считать идентификаторы действующих на них рестрикторов. Если ваша аномалия будет в этом списке - удалять её нельзя. Дождитесь пока она освободится.

== Вылет при открытии закладки "Контакты" в ПДА ==

Простой безлоговый вылет при открытии закладки "Контакты". Встречался во всех крупных модах, и никто не знал как его излечить. А лечится он банально - '''его причина - дублирование идентификаторов секций в XML-файле, описывающем иконки неписей для закладки "Контакты"'''. Нужно всего лишь проверить этот файл на наличие дублированных идентификаторов и удалить их. Вылет пропадёт и никогда больше не будет встречаться.

== Вылеты при вызове несуществующих функций из XML ==

В ХML-файлах, используемых для описания инфопоршенов, для многих инфопоршенов прописаны действия, которые игра вызывает при взятии этого инфопоршена. Вот так примерно:

<code xml>
<info_portion id="barman_document_have">
<action>dialogs.set_actor_prebandit1</action>
<action>bar_spawn.bandits2</action>
<action>bar_spawn.bandits3</action>
<action>bar_spawn.bandit7</action>
<action>bar_spawn.bandit8</action>
</info_portion>
</code>

Так вот, если вы допустите опечатку в названии вызываемой функции или же случайно её удалите - игра будет стабильно вылетать без лога при взятии этого инфопоршена.

== Повреждения сейвов на Радаре и других местах в модах, основанных на OGSM ==

В оригинале ОГСМ и основанных на нём модах часто встречались проблемы с сохранениями на Радаре. Эту проблему долго не удавалось победить, пока наконец благодаря помощи Маландринуса не удалось выявить её первопричину. Как выяснилось, она очень проста - гражданские зомби в моде (монстры) имели в конфиге ту же пропись вида (параметр конфига specie), что и монолитовцы и зомбированные (неписи). И там и тут было проставлено "zombie", и так оно было ещё с оригинала. Как оказалось, так делать категорически нельзя. Дело в том, что неписей есть такой функционал, как хитовая память - в ней какое-то время хранятся ссылки на атакующие объекты. У монстров тоже есть остатки этого функционала, но он неработоспособен, и использовать его нельзя. В случае же когда монстры и неписи попадают в один вид, в ситуации когда они находятся рядом в бою, хитовая память монстров автоматически получает от неписей того же вида распространяемую внутри вида информацию об атакующих - а хранить её монстрам нельзя. Если после создания такой ситуации сохраниться - сейв будет вызывать вылет при загрузке. То есть проще говоря, если в бою с монолитовцами рядом оказывались гражданские зомби - и игрок сохранял игру - сейв этот не загружался. Чтобы предотвратить эти проблемы, вполне достаточно создать для гражданских зомби свой отдельный вид, добавив его прописи в конфиг game_relations.

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 11:04, 3 сентября 2009 (UTC)

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

[[Категория:Скрипты]]

Как писать скрипты, не приводящие к вылетам и бою сейвов (часть 2)

2010-02-19T18:36:29Z

Kamikazze:

[[Категория:Статьи участников]]
[[Категория:Скрипты]]

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Как безопасно использовать коллбэки и таймерные события =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Использование защищённого кода в LUA =

Периодически случаются такие ситуации, когда мы можем получить вылет при проверке аргумента, и не можем его адекватно заизолировать с помощью предварительной проверки на валидность значения. Вот простой пример: когда я отлаживал '''death_callback''' неписей, я периодически сталкивался с тем, что обращение к методу '''smart_terrain_id()''' при смерти непися иногда вызывало вылет

<code>smart_terrain:1143 "attempt to index a nil value"</code>

- хотя это свойство является родным методом объекта, и отсутствовать напрочь никак не может. В итоге я пришёл к выводу, что его просто иногда не успевает отработать движок, так как вылет этот проявлялся в основном в интенсивных боях и совершенно произвольно.

Вот код, в котором происходил вылет:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- вылет происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id)
end
end
end</code>

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

'''pcall (f, arg1, ···)'''

<blockquote>Вызывает функцию f с указанными через запятую аргументами в защищённом режиме. Это означает, что любая ошибка, даже критическая, внутри вызыванной функции, не передаётся наружу - вызавшей подсистеме. Вместо этого '''pcall''' перехватывает ошибку и возвращает код статуса. Первая возвращаемая переменная это сам код, (true или false) и если всё прошло хорошо, он равен true. В этом случае '''pcall''' сразу после статуса возвращает все результаты от работы защищённой им функции. Если же в защищённой функции произошла ошибка, то '''pcall''' вернёт false и затем сообщение об ошибке. (Обратите внимание, обработка ошибки присходит БЕЗ вылета! Вместо вылета вы получите вполне адекватную строку с ошибкой, которую можно вывести в лог для последующей обработки)</blockquote>

Я настоятельно советую пользоваться этой функцией в случаях, когда из коллбэков вызываются сложные комплексные обработки, вроде обработки из менеджера вооружений AI-пака. Это позволяет предотвратить как вылеты, так и зависания обработок, и в итоге позволяет хорошо стабилизировать игру.

Возвращаясь к нашим смарттеррейнам... вот как в итоге я подавил вылет типа smart_terrain:1143 с помощью pcall:

<code lua>--- эта функция пытается проверить св-во smart_terrain_id объекта. Именно её мы вызовем в защищённом режиме.
function prot_smt_td(obj)
if IsStalker(obj) or IsMonster(obj) then
return obj:smart_terrain_id()
else
return 65535
end
end

function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if obj then
local strn_id = 65535 --- предварительно проинитим переменную, на
--- случай если у нас prot_smt_td выдаст ошибку
local result, smt_id = pcall(prot_smt_td,obj) --- вызываем prot_smt_td в защищённом режиме
--- и сразу присваиваем его вывод переменным
if result then --- если pcall выдало true
strn_id = smt_id --- тогда применям полученное значение
end
--- если же обработка выдаст ошибку, то strn_id останется неизменным...
if strn_id ~= 65535 then
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end</code>

В других местах это делается совершенно аналогично. Подробнее об этой и многих других функция для контроля кода, незаслуженно ингорируемых большинством моддеров, можно почитать тут: http://lua-users.org/wiki/FinalizedExceptions - на английском правда, но захотите - разберётесь, там всё просто.

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

= Скрытые критические проблемы в обработке вылетов игрой =

Ведя на днях отладку, выяснил в чём проблема с периодическим боем сейвов и многими другими заморочками как в оригинае игры, так и во многих модах... дело, как выяснилось, далеко не всегда в кривых руках. Существует есть такая стандартная ф-ция '''abort''' - предназначенная для выкидывания из игры, если что-то пошло не так. И как оказалось, она срабатывает далеко не всегда. Выяснилось это следующим образом:

В одном из логов нашего бета-тестера я увидел '''стандартное сообщение о вылете внутри рабочего лога'''... да-да, то самое которое '''FATAL ERROR''' и дальше по тектсу. При этом игра у него НЕ вылетала, это сообщение об ошибке мы обнаружили позже, по случайности. Я заподозрил, что что-то не в порядке, и вставил внутрь этой ф-ции контрольную метку, кидавшую в консоль сообщение, в котором содержался паттерн сообщения об ошибке и само сообщение. Так вот, оказалось, что эта самая ф-ция '''abort''' вызывается в игре с завидным постоянством (вы удивитесь насколько часто), когда возникают исключения в схемах логики, звука и т.д., но игра от этого вылетает на рабочий стол '''максимум только 3 раза из 10 вызовов'''. Вылет НЕ происходит обычно, когда ф-ции передан паттерн ошибки, а остальные параметры пустые, такое бывает, и частенько. И если не сделать внутри этой ф-ции особой метки для вывода в лог, как сделал это я, её вызовы проходят совершенно незаметно, и '''игра после критических ошибок продолжается как ни в чём ни бывало.''' А приводит это вот к чему... Внутри '''xr_logic''' в процедуре записи пстора (хранилища логики и флагов) неписей есть вызовы этого самого аборта в случае если на запись в пстор передана некорректная величина. Ну а так как аборт периодически вообще не срабатывает, то часто попадается ситуация, что неписям в пстор пишется полный ахтунг: куски кода из ОЗУ, всякая муть из лтх-ов, куски аллспавна, всё что угодно. Происходит это оттого, что кодер, писавший эту ф-цию ('''xr_logic.pstor_store(obj, varname, val)'''), явно и думать не думал что '''abort''' может не сработать. У него запись в пстор стояла после провеки, а не внутри неё (very bad idea), и если abort не срабатывал, игра писала в пстор мусор совершенно спокойно и незаметно для игрока. Потом вся эта хрень попадала прямо в сейвы. Вот проблемный код для наглядности:

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv) --- вот тут мы должны если что вылететь
end
db.storage[npc_id].pstor[varname] = val -- а если не вылетели, всё, получим запись в пстор левой мути
end</code>

Разумеется игра этим пстором в итоге давится, и сейвы сделанные после такой милой записи практически лопаются. Результат - "битые" (на самом деле подлежат реанимации) сейвы. Происходит это потому, что игра из сейва грузит неписям псторы сплошным чтением по словам, пока они не закончатся. В случае же если в псторе обнаруживается записанный ранее мусор, то обработка либо вылетает сразу, либо наглухо виснет, пытаясь запихать эдак с миллион слов в пстор особо отличившегося непися. Как вам например непись с размером пстора в 1697451 слова? В результате попытки его обработать игра просто на стадии синхронизации выжрала всю доступную ОЗУ и повисла.

Решение этой проблемы оказалось достатоно простым: во-первых я предположил максимальный размер полезной части пстора неписей в 20 слов r_u32() (пока ориентировочно, я ещё уточняю эту величину), и соответственно сделал остановку цикла загрузки пстора для неписей через 20 итераций. Там же, где в цикле стояла проверка на валидность записываемых данных (кстати тоже с вылетом в случае провала проверки), я сделал так, что если параметр не относится к валидному типу данных, то запись параметра в пстор не производится совсем. Это необходимо для того, чтобы если вдруг в сейве обнаружится мусор, то он был бы просто отброшен обработкой. Практика показала, что в итоге такие неписи вполне адекватны и в дальнейшем никаких проблем не вызывают, так как начало их пстора, с нормальными данными, обычно не повреждается - мусор дописывается после них, а не вместо них.

Ну и во-вторых модифицировал запись параметров в пстор, просто убрав запись под основание if-else так, чтобы если параметр неверен, он не записывался совсем. Теперь кстати, очень интересно, сохранились ли те же заморочки с ф-цией '''abort''' в Чистом Небе, и если да, то останутся ли в Зове Припяти?

------------

== Необходимые для стабилизации игры правки в модулях ==

'''Эта правка предотвращает запись в пстор если не сработал аборт:'''

''xr_logic.script''

'''Было:'''

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv)
end
db.storage[npc_id].pstor[varname] = val
end</code>

'''Стало:'''

<code lua>function pstor_store(obj, varname, val)
if not obj then return end
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
dgblog("xr_logic: pstor_store: not registered type encountered - write in pstor_store cancelled")
-- abort убран, так как один хрен не работает. Пусть тогда хотя бы в лог что-то валится.
else
db.storage[npc_id].pstor[varname] = val
-- вот так и только так. Если значение не валидно, ничего не происходит.
end
end</code>

'''А эта правка выкинет из пстора весь мусор при загрузке сейва, если он как-то в него попал'''

'''Было:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
abort("xr_logic: pstor_load_all: not registered type N %d encountered", tn)
end
printf("_bp: pstor_load_all: loaded [%s]='%s'", varname, utils.to_str(pstor[varname]))
end
end</code>

'''Стало:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
if tonumber(ctr) > 20 and tostring(obj:name()) ~= "single_player" and npc_id ~= db.actor:id() then
-- максимум 20 итераций - это число ещё уточняется, возможно понадобится больше
-- если у вас в пстор что-то свое пишется, ориентируйтесь на свои значения
-- и обязательно убираем из проверки актора - у него очень толстый пстор, и к тому же
-- если уж поврежденным будет его пстор, то тут точно уже ничего не поможет
dgblog("ОБНАРУЖЕН ОБЪЕКТ С ПОВРЕЖДЕННЫМ PSTOR: "..tostring(obj:name())..
" БУДЕТ ПРОИЗВЕДЕНА ПОПЫТКА ВОССТАНОВЛЕНИЯ")
ctr = 20
end
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
-- не надо пытаться вылетать - просто не пишем поврежденные данные
-- при этом обязательно удалять саму переменную - в результате записи
-- мусора в пстор одно только ее название может повесить загрузку
pstor[varname] = nil
end
end
end</code>

Эти примеры приведены для чистой игры. Единственное в чем не уверен пока, это в том, что максимум полезного размера - 20 слов. Возможно нужно выделить больше, это надо будет проверить ещё экспериментальным путем...

Кроме этого, советую ещё внутрь ф-ции abort вставить отладочные метки, чтобы точно знать когда она вызывалась. Настоятельно советую сделать это даже если вы матёрый моддер со стажем - гарантирую, будете неприятно удивлены.

Я это сделал вот так:

''_g.script''

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
end</code>

= Другие частые проблемы =

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

== Вылеты при удалении объектов из игры ==

При использовании для удаления объектов родной движковой функции '''alife():release(obj:id(), true)''' возможен целый ворох разнообразнейших вылетов, обычно - безлоговых, что сильно затрудняет их отладку. Вот из-за чего они возникают:

1) Вылет при удалении непися или монстра.
Решение: с помощью alife():release '''можно удалять только мёртвые объекты'''. Поэтому если вам нужно удалить с её помощью непися или монстра, его нужно убить любым доступным методом, хотя бы нанеся ему hit() с любым запредельным уроном по вкусу.

2) Вылет при удалении оружия или артефакта.
Решение: такая проблема часто встречается в случае если объект неудачно расположен или находится в руках у непися. Для того чтобы не произошло вылета, убедитесь что объект доступен как серверный перед удалением. Вот так:

<code lua> local obj = alife():object(i)
if obj then
alife():release(obj, true)
end</code>

Эту конструкцию вообще желательно использовать всегда, когда вы так удаляете объекты.

3) Вылет при удалении аномалии.
Решение: аномалии - очень капризные при подобном с ними обращении объекты. Они влияют на своё окружение, и если рядом с ними находится непись или монстр, то удаление такой аномалии приведёт к вылету игры. Чтобы этого не произошло, аномалию надо сначала выключить функцией '''disable_anomaly''', и удалять затем ТОЛЬКО тогда, когда она не будет занята влиянием на динамический объект. Для этого нужно получить список мобов на локации, и из их нетпакетов считать идентификаторы действующих на них рестрикторов. Если ваша аномалия будет в этом списке - удалять её нельзя. Дождитесь пока она освободится.

== Вылет при открытии закладки "Контакты" в ПДА ==

Простой безлоговый вылет при открытии закладки "Контакты". Встречался во всех крупных модах, и никто не знал как его излечить. А лечится он банально - '''его причина - дублирование идентификаторов секций в XML-файле, описывающем иконки неписей для закладки "Контакты"'''. Нужно всего лишь проверить этот файл на наличие дублированных идентификаторов и удалить их. Вылет пропадёт и никогда больше не будет встречаться.

== Вылеты при вызове несуществующих функций из XML ==

В ХML-файлах, используемых для описания инфопоршенов, для многих инфопоршенов прописаны действия, которые игра вызывает при взятии этого инфопоршена. Вот так примерно:

<code xml>
<info_portion id="barman_document_have">
<action>dialogs.set_actor_prebandit1</action>
<action>bar_spawn.bandits2</action>
<action>bar_spawn.bandits3</action>
<action>bar_spawn.bandit7</action>
<action>bar_spawn.bandit8</action>
</info_portion>
</code>

Так вот, если вы допустите опечатку в названии вызываемой функции или же случайно её удалите - игра будет стабильно вылетать без лога при взятии этого инфопоршена.

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 11:04, 3 сентября 2009 (UTC)

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

Как писать скрипты, не приводящие к вылетам и бою сейвов (часть 2)

2009-09-03T16:06:52Z

Kamikazze: Категория, Ссылка на 1-ю часть

[[Категория:Статьи участников]]
[[Категория:Скрипты]]

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Как безопасно использовать коллбэки и таймерные события =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Использование защищённого кода в LUA =

Периодически случаются такие ситуации, когда мы можем получить вылет при проверке аргумента, и не можем его адекватно заизолировать с помощью предварительной проверки на валидность значения. Вот простой пример: когда я отлаживал '''death_callback''' неписей, я периодически сталкивался с тем, что обращение к методу '''smart_terrain_id()''' при смерти непися иногда вызывало вылет

<code>smart_terrain:1143 "attempt to index a nil value"</code>

- хотя это свойство является родным методом объекта, и отсутствовать напрочь никак не может. В итоге я пришёл к выводу, что его просто иногда не успевает отработать движок, так как вылет этот проявлялся в основном в интенсивных боях и совершенно произвольно.

Вот код, в котором происходил вылет:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- вылет происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id)
end
end
end</code>

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

'''pcall (f, arg1, ···)'''

<blockquote>Вызывает функцию f с указанными через запятую аргументами в защищённом режиме. Это означает, что любая ошибка, даже критическая, внутри вызыванной функции, не передаётся наружу - вызавшей подсистеме. Вместо этого '''pcall''' перехватывает ошибку и возвращает код статуса. Первая возвращаемая переменная это сам код, (true или false) и если всё прошло хорошо, он равен true. В этом случае '''pcall''' сразу после статуса возвращает все результаты от работы защищённой им функции. Если же в защищённой функции произошла ошибка, то '''pcall''' вернёт false и затем сообщение об ошибке. (Обратите внимание, обработка ошибки присходит БЕЗ вылета! Вместо вылета вы получите вполне адекватную строку с ошибкой, которую можно вывести в лог для последующей обработки)</blockquote>

Я настоятельно советую пользоваться этой функцией в случаях, когда из коллбэков вызываются сложные комплексные обработки, вроде обработки из менеджера вооружений AI-пака. Это позволяет предотвратить как вылеты, так и зависания обработок, и в итоге позволяет хорошо стабилизировать игру.

Возвращаясь к нашим смарттеррейнам... вот как в итоге я подавил вылет типа smart_terrain:1143 с помощью pcall:

<code lua>--- эта функция пытается проверить св-во smart_terrain_id объекта. Именно её мы вызовем в защищённом режиме.
function prot_smt_td(obj)
if IsStalker(obj) or IsMonster(obj) then
return obj:smart_terrain_id()
else
return 65535
end
end

function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if obj then
local strn_id = 65535 --- предварительно проинитим переменную, на
--- случай если у нас prot_smt_td выдаст ошибку
local result, smt_id = pcall(prot_smt_td,obj) --- вызываем prot_smt_td в защищённом режиме
--- и сразу присваиваем его вывод переменным
if result then --- если pcall выдало true
strn_id = smt_id --- тогда применям полученное значение
end
--- если же обработка выдаст ошибку, то strn_id останется неизменным...
if strn_id ~= 65535 then
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end</code>

В других местах это делается совершенно аналогично. Подробнее об этой и многих других функция для контроля кода, незаслуженно ингорируемых большинством моддеров, можно почитать тут: http://lua-users.org/wiki/FinalizedExceptions - на английском правда, но захотите - разберётесь, там всё просто.

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

= Скрытые критические проблемы в обработке вылетов игрой =

Ведя на днях отладку, выяснил в чём проблема с периодическим боем сейвов и многими другими заморочками как в оригинае игры, так и во многих модах... дело, как выяснилось, далеко не всегда в кривых руках. Существует есть такая стандартная ф-ция '''abort''' - предназначенная для выкидывания из игры, если что-то пошло не так. И как оказалось, она срабатывает далеко не всегда. Выяснилось это следующим образом:

В одном из логов нашего бета-тестера я увидел '''стандартное сообщение о вылете внутри рабочего лога'''... да-да, то самое которое '''FATAL ERROR''' и дальше по тектсу. При этом игра у него НЕ вылетала, это сообщение об ошибке мы обнаружили позже, по случайности. Я заподозрил, что что-то не в порядке, и вставил внутрь этой ф-ции контрольную метку, кидавшую в консоль сообщение, в котором содержался паттерн сообщения об ошибке и само сообщение. Так вот, оказалось, что эта самая ф-ция '''abort''' вызывается в игре с завидным постоянством (вы удивитесь насколько часто), когда возникают исключения в схемах логики, звука и т.д., но игра от этого вылетает на рабочий стол '''максимум только 3 раза из 10 вызовов'''. Вылет НЕ происходит обычно, когда ф-ции передан паттерн ошибки, а остальные параметры пустые, такое бывает, и частенько. И если не сделать внутри этой ф-ции особой метки для вывода в лог, как сделал это я, её вызовы проходят совершенно незаметно, и '''игра после критических ошибок продолжается как ни в чём ни бывало.''' А приводит это вот к чему... Внутри '''xr_logic''' в процедуре записи пстора (хранилища логики и флагов) неписей есть вызовы этого самого аборта в случае если на запись в пстор передана некорректная величина. Ну а так как аборт периодически вообще не срабатывает, то часто попадается ситуация, что неписям в пстор пишется полный ахтунг: куски кода из ОЗУ, всякая муть из лтх-ов, куски аллспавна, всё что угодно. Происходит это оттого, что кодер, писавший эту ф-цию ('''xr_logic.pstor_store(obj, varname, val)'''), явно и думать не думал что '''abort''' может не сработать. У него запись в пстор стояла после провеки, а не внутри неё (very bad idea), и если abort не срабатывал, игра писала в пстор мусор совершенно спокойно и незаметно для игрока. Потом вся эта хрень попадала прямо в сейвы. Вот проблемный код для наглядности:

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv) --- вот тут мы должны если что вылететь
end
db.storage[npc_id].pstor[varname] = val -- а если не вылетели, всё, получим запись в пстор левой мути
end</code>

Разумеется игра этим пстором в итоге давится, и сейвы сделанные после такой милой записи практически лопаются. Результат - "битые" (на самом деле подлежат реанимации) сейвы. Происходит это потому, что игра из сейва грузит неписям псторы сплошным чтением по словам, пока они не закончатся. В случае же если в псторе обнаруживается записанный ранее мусор, то обработка либо вылетает сразу, либо наглухо виснет, пытаясь запихать эдак с миллион слов в пстор особо отличившегося непися. Как вам например непись с размером пстора в 1697451 слова? В результате попытки его обработать игра просто на стадии синхронизации выжрала всю доступную ОЗУ и повисла.

Решение этой проблемы оказалось достатоно простым: во-первых я предположил максимальный размер полезной части пстора неписей в 20 слов r_u32() (пока ориентировочно, я ещё уточняю эту величину), и соответственно сделал остановку цикла загрузки пстора для неписей через 20 итераций. Там же, где в цикле стояла проверка на валидность записываемых данных (кстати тоже с вылетом в случае провала проверки), я сделал так, что если параметр не относится к валидному типу данных, то запись параметра в пстор не производится совсем. Это необходимо для того, чтобы если вдруг в сейве обнаружится мусор, то он был бы просто отброшен обработкой. Практика показала, что в итоге такие неписи вполне адекватны и в дальнейшем никаких проблем не вызывают, так как начало их пстора, с нормальными данными, обычно не повреждается - мусор дописывается после них, а не вместо них.

Ну и во-вторых модифицировал запись параметров в пстор, просто убрав запись под основание if-else так, чтобы если параметр неверен, он не записывался совсем. Теперь кстати, очень интересно, сохранились ли те же заморочки с ф-цией '''abort''' в Чистом Небе, и если да, то останутся ли в Зове Припяти?

------------

== Необходимые для стабилизации игры правки в модулях ==

'''Эта правка предотвращает запись в пстор если не сработал аборт:'''

''xr_logic.script''

'''Было:'''

<code lua>function pstor_store(obj, varname, val)
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
abort("xr_logic: pstor_store: not registered type '%s' encountered", tv)
end
db.storage[npc_id].pstor[varname] = val
end</code>

'''Стало:'''

<code lua>function pstor_store(obj, varname, val)
if not obj then return end
local npc_id = obj:id()
if db.storage[npc_id].pstor == nil then
db.storage[npc_id].pstor = {}
end
local tv = type(val)
if not pstor_is_registered_type(tv) then
dgblog("xr_logic: pstor_store: not registered type encountered - write in pstor_store cancelled")
-- abort убран, так как один хрен не работает. Пусть тогда хотя бы в лог что-то валится.
else
db.storage[npc_id].pstor[varname] = val
-- вот так и только так. Если значение не валидно, ничего не происходит.
end
end</code>

'''А эта правка выкинет из пстора весь мусор при загрузке сейва, если он как-то в него попал'''

'''Было:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
abort("xr_logic: pstor_load_all: not registered type N %d encountered", tn)
end
printf("_bp: pstor_load_all: loaded [%s]='%s'", varname, utils.to_str(pstor[varname]))
end
end</code>

'''Стало:'''

<code lua>function pstor_load_all(obj, reader)
local npc_id = obj:id()
local pstor = db.storage[npc_id].pstor
if not pstor then
pstor = {}
db.storage[npc_id].pstor = pstor
end
local ctr = reader:r_u32()
if tonumber(ctr) > 20 and tostring(obj:name()) ~= "single_player" and npc_id ~= db.actor:id() then
-- максимум 20 итераций - это число ещё уточняется, возможно понадобится больше
-- если у вас в пстор что-то свое пишется, ориентируйтесь на свои значения
-- и обязательно убираем из проверки актора - у него очень толстый пстор, и к тому же
-- если уж поврежденным будет его пстор, то тут точно уже ничего не поможет
dgblog("ОБНАРУЖЕН ОБЪЕКТ С ПОВРЕЖДЕННЫМ PSTOR: "..tostring(obj:name())..
" БУДЕТ ПРОИЗВЕДЕНА ПОПЫТКА ВОССТАНОВЛЕНИЯ")
ctr = 20
end
for i = 1, ctr do
local varname = reader:r_stringZ()
local tn = reader:r_u8()
if tn == pstor_number then
pstor[varname] = reader:r_float()
elseif tn == pstor_string then
pstor[varname] = reader:r_stringZ()
elseif tn == pstor_boolean then
pstor[varname] = reader:r_bool()
else
-- не надо пытаться вылетать - просто не пишем поврежденные данные
-- при этом обязательно удалять саму переменную - в результате записи
-- мусора в пстор одно только ее название может повесить загрузку
pstor[varname] = nil
end
end
end</code>

Эти примеры приведены для чистой игры. Единственное в чем не уверен пока, это в том, что максимум полезного размера - 20 слов. Возможно нужно выделить больше, это надо будет проверить ещё экспериментальным путем...

Кроме этого, советую ещё внутрь ф-ции abort вставить отладочные метки, чтобы точно знать когда она вызывалась. Настоятельно советую сделать это даже если вы матёрый моддер со стажем - гарантирую, будете неприятно удивлены.

Я это сделал вот так:

''_g.script''

<code lua>-- Крешнуть игру (после вывода сообщения об ошибке в лог)
function abort(fmt, msg)
local message = tostring(msg)
dbglog("ERROR PATTERN: "..tostring(fmt))
dbglog("ERROR REASON: "..message)
local reason = string.format(fmt, message)
assert("ERROR: " .. reason)
printf("ERROR: " .. reason)
dbglog("%s", reason)
printf("%s")
end</code>

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 11:04, 3 сентября 2009 (UTC)

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

Как писать скрипты, не приводящие к вылетам и бою сейвов

2009-09-03T16:05:36Z

Kamikazze: Категория, ссылка на 2-ю часть

[[Категория:Статьи участников]]
[[Категория:Скрипты]]

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов (часть 2)|Продолжение во второй части]]

----

= Предисловие =

'''Отладив несколько скриптов на предмет вылетов решил написать это небольшое руководство, чтобы помочь начинающим (да и опытным тоже) скриптописателям избежать потенциальных проблем.'''

Сразу оговорюсь — я программист, поэтому к отладке скриптов подхожу со своей профессиональной точки зрения, и то что я тут изложу вам — сие для программиста есть непреложная истина, и если вы хотите уменьшить количество глюков — старайтесь придерживаться нижеприведённого стиля программирования.

Для начала маленький экскурс в историю. Итак, скрипты в сталкере написаны на языке '''Lua''' — разработали его бразильцы, он очень гибок, легко встраивается в игры и поэтому очень часто используется для написания скриптов любой степени сложности. Так вот, у этого языка и его реализации в игре есть несколько исключительно важных особенностей, которые, при их несоблюдении, будут приводить к вылетам вашего скрипта. Итак:

= Типы данных и проблемы с nil. =

Сначала сделаю маленькое отступление для не знакомых с основами скриптеров, чтобы понятнее было. Итак, в Lua используются следующие логические операторы:

<code>
= оператор присваивания
== сравнение, равно ли значение
≈ сравнение, НЕ равно ли значение
< сравнение, меньше ли значение
> сравнение, больше ли значение
<= сравнение, меньше ли значение или равно
>= сравнение, больше ли значение или равно
and логический оператор И
not логический оператор НЕ
or логический оператор ИЛИ</code>

Всё. Теперь поехали дальше… Язык Lua Изначально создавался для работы с большими строчными базами данных, поэтому ВСЕ виды конструкций в языке — это типы данных, то есть по сути либо переменные, либо константы. Это касается так же и функций! '''Поэтому даже с функциями в Lua можно и нужно обращатся как с переменными.''' Далее. Касательно, собственно «привычных» переменных. '''Обычные переменные в Lua получают свой тип данных только в момент присвоения им значения (запомните, это важно).''' При этом, в Lua есть такой важный и полезный тип данных как nil. nil — Это «пустота», то есть отсутствие какого-либо значения. При этом этот тип используется компилятором скриптов для «сбора мусора», то есть для освобождения занимаемой памяти. Смотрите пример, я объясню подробнее, что это значит:

<code lua>local reminder_count
local exposure_count = 0</code>

Тут у нас 2 локальные переменные, одна из которых просто создана, а вторая — создана и инициализарована. Если сейчас обратиться к переменной reminder_count, считав её значение, то мы получим в качестве значения — nil, то есть пустоту. Если же мы обратимся к переменной exposure_count — то получим, как и ожидали, 0 — так как мы это значение проинициализировали ЗАРАНЕЕ. '''При этом не надо путать nil и 0 — так как 0 — это всё-таки какая-то информация, а вот nil — это её полное отсутствие.''' Так вот, собственно, чем это чревато. Я уже сказал, что nil используется для сбора мусора. Вручную это работает так — когда вам переменная уже не нужна, вы просто пишете:

<code lua>test_variable = nil</code>

И ваша переменная test_variable сотрётся из памяти, и любые ссылки на неё будут выдавать на выходе nil (типа нет такой переменной, «абонент вне зоны действия сети»). Ну так собственно вот, зачем я это всё рассказываю… '''если не определить значение переменной сразу, как это было сделано с переменной reminder_count, то любые попытки обратиться к ней внутри скрипта приведут к вылетам.''' Происходит это следующим образом: допустим, reminder_count — это у нас счётчик напоминаний. То есть мы о чём-то напоминаем игроку текстовыми сообщениями, и помечаем, сколько раз мы это сделали. Определили мы переменную именно так, как в примере выше, то есть не задав ей никакого значения. Значение же её должно присваиваться ниже по коду, после первого оповещения юзера. При этом у нас есть в коде обращение к этой переменной, по которому решается что делать дальше. Выглядит это примерно так:

<code lua>function check_antirad_supplies()

if auto_injection_active then

if antirad_check_delay == nil or game.get_game_time():diffSec(antirad_check_delay) > 60 then

if not db.actor:object(«antirad») and not (use_scientific_kit and db.actor:object(«medkit_scientic»)) then

--обратите внимание сюда
if reminder_count == 0 or reminder_count >= mins_till_next_remind then
--обратите внимание сюда
if use_text then
local news_text = «%c[255,160,160,160]Автоматическая система ввода медицинских
препаратов\\n".."%c[default]Напоминаю: %c[255,230,0,0]
Противорадиационные препараты отстутствуют! %c[default]
Автоматический ввод препаратов невозможен.»
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal",
Frect():set(0,188,83,47), 0, 3000)
end
if use_sounds then
local snd_obj
if use_custom_sounds then
snd_obj = xr_sound.get_safe_sound_object([[HEV\no-anti-rad]])
else
snd_obj = xr_sound.get_safe_sound_object([[device\pda\pda_tip]])
end
if snd_obj then
snd_obj:play_no_feedback(db.actor, sound_object.s2d, 0, vector(), 1.0)
end
end
reminder_count = 1
elseif reminder then
reminder_count = reminder_count + 1
end

else
radiation_warning = true
reminder_count = 0
end
antirad_check_delay = game.get_game_time()
end
end
end</code>

Во время игры всё это скорее всего отработает хорошо, но вот при загрузке… тут могут быть проблемы, так как скрипт при запуске может пролететь ту часть, где переменной reminder_count присваивается значение! В итоге при запуске вышеприведённой функции check_antirad_supplies() нас получится что reminder_count не существует — он равен nil, и в итоге проверка

<code lua>if reminder_count == 0 or reminder_count >= mins_till_next_remind then</code>

выдаст ошибку и приведёт к вылету! Почему? '''Да потому что НЕЛЬЗЯ сравнивать НИЧТО с вещественным значением.''' Именно поэтому, когда вы создаёте новую переменную, вы ОБЯЗАНЫ задать ей значение по умолчанию, даже если вы полностью уверены, что она нигде не будет использована до инициализации. Поверьте — в программировании бывает всё, и запросто может так случиться, что ваша переменная будет использована и спровоцирует вылет.

Простой способ обойти такую кучу проверок и лишних инициализаций — использование or-оператора. пример

<code lua>if (reminder_count or 0) >= mins_till_next_remind then</code>

если переменная равна nil, то выражение вычисляется дальше и получается равным 0, а это уже число и сравнение происходит безболезненно.

Кроме вышеприведённой ситуации, возможен ещё один неприятный момент, связанный с определением переменных и значением nil. Суть его заключается в том, что при присваивании значений или операциями с переменными мы можем получить кучу проблем… покажу конкретнее каких:

== «Смерть» переменных ==

Положим, у нас с reminder_count происходят ещё какие-нибудь занимательные вещи, например мы его значение зачем-нибудь присваиваем другой переменной вот так:

<code lua>antirad_check_delay = reminder_count</code>

Ну и вот, если у нас reminder_count в момент присвоения ещё не имеет никакого значения, то мы получим занимательную штуку — у нас это выражение сработает как

<code lua>antirad_check_delay = nil</code>

В результате чего переменная antirad_check_delay «сдохнет» и будет деловито убрана «сборщиком мусора» из памяти, что моментально приведёт к вылету, когда в дальнейшем какая-то часть кода обратится к значению antirad_check_delay.

== Ошибки деления на 0 ==

Теперь положим что у нас reminder_count используется в каком-нибудь расчёте вот так:

<code lua>antirad_check_delay = exposure_count/reminder_count</code>

Как мы помним, у нас reminder_count не инициализирована, и как следствие равна nil. В итоге мы получим попытку поделить exposure_count на ноль (в нашем случае на nil, что суть одно и то же в нашем случае) и получим «классический» программистский вылет из-за ошибки деления на ноль.

== Ошибки присвоения ==

Предположим что мы написали скрипт, который помогает выбирать оружие при наличии вблизи врагов. И вот, у нас в скрипте есть такой кусок кода, где NPC вынимает из рюкзака оружие:

<code lua>function weapon_manager:set_weapon(wpn)

local enemy = self.npc:best_enemy()
if wpn then
--обратите внимание сюда
self.weapon_id = wpn:id()
--обратите внимание сюда
self:return_items(self.weapon_id)
else
printw(«set_wpn:weapon not exist»)
end
if self.modes.process_mode == "3" and enemy then
for k, v in pairs(self.weapons) do
for i, w in ipairs(v) do
if w.id ≈ self.weapon_id then
local item = level.object_by_id(w.id)
if item and item:parent() and item:parent():id() == self.npc_id then
printw(«set_weapon[%s]:process %s[%s]», self.npc:character_name(), w.id, w.sec)
self:process_item(item)
end
end
end
end
end
if enemy then
self.npc:set_item(object.idle, wpn)
end
self.weapons = nil

end</code>

В помеченном выражении self.weapon_id = wpn:id(), и всё вроде бы отлично, так как стоит проверка if wpn then, однако иногда движок умудряется передать объект функциям некорректно, либо сам скриптер может перепутать при вызове игровой объект с объектом а-лайфа, и присвовение self.weapon_id = wpn:id() либо приравняет self.weapon_id к nil либо сразу приведёт к вылету из-за того что соответствующее свойство объекта не было обнаружено в его классе.

== Как с этим бороться ==

Бороться с такими ситуациями очень просто на самом деле.
Во-первых: ВСЕГДА ИНИЦИАЛИЗИРУЙТЕ ПЕРЕМЕННЫЕ. То есть вот такое описание переменной:

<code>local reminder_count</code>

НЕДОПУСТИМО! ВЫ ОБЯЗАТЕЛЬНО ДОЛЖНЫ ЗАДАТЬ ПЕРЕМЕННОЙ ЗНАЧЕНИЕ!
Если переменная числовая, сделайте это так:

<code>local reminder_count = 0</code>

Если строчная — то сделайте это так:

<code>local reminder_count = ""</code> (получится вместо nil пустая строка)

Если логическая, то так:

<code>local reminder_count = false</code>

В общем, делайте так, как вам удобнее, но ДЕЛАЙТЕ ОБЯЗАТЕЛЬНО!

И во-вторых: ВСЕГДА ПРОВЕРЯЙТЕ ПЕРЕМЕННУЮ ПЕРЕД ИСПОЛЬЗОВАНИЕМ!

То есть в кусках кода, чреватых вылетами (к ним относятся АБСОЛЮТНО ВСЕ части, где идёт работа с вещами или оружием) обязательно вставляйте проверки переменных на nil следующим образом:

<code lua>if wpn and wpn:id() then
self.weapon_id = wpn:id()
end</code>

Тогда сначала выполнится проверка, и если обе переменные имеют значение, то операция отработает, а если один из параметров пуст — то функция просто пропустит этот код. Тут не помешает ещё и проверку вставить на существование self.weapon_id, хотя это наверное уже моя параноя :)

Кстати, что самое дурацкое — ошибки, приведённые выше, часто в лог попадают совершенно непохожим на ошибки скриптов образом. Например, ошибка присвоения из примера 3 приводила к вылету с сообщением «Assertion failed», и поймать её я смог только изучив внимательно предыдущие строки лога, где зафиксировались операции с вещами…

Точно так же, если вы используете ЛЮБЫЕ математические операции например деление (но не только деление, всего остального тоже касается), тоже ОБЯЗАТЕЛЬНО поверяйте переменную. Вот так:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
end</code>

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

<code lua>if wpn and wpn:id() then
self.weapon_id = wpn:id()
end</code>

Или таким:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
end</code>

И у вас в случае некорректного значения компилятор спокойно пропустил этот код, ничего не сделав ни с self.weapon_id (из первого примера), ни с antirad_check_delay (из второго). Однако вам всё-таки нужно, чтобы с ними что-то происходило, даже если проверяемые переменные неверны. Тогда я бы советовал вам дополнить этот обход отработкой нештатной ситуации. Делается это банально просто:

<code lua>if wpn and wpn:id()then
self.weapon_id = wpn:id()
elseif wpn == nil then
--вставьте сюда код, что делать если wpn не существует
elseif wpn:id() == nil then
--а сюда, если wpn:id() не существует
--тут скорее всего перепутан объект, и можно попробовать
--обратиться к wpn.id
end</code>

И для второго случая аналогично:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
else
--а тут что мы сделаем если reminder_count не существует
--я бы сделал например вот так:
antirad_check_delay = exposure_count/1
--и все дела
end</code>

Более конкретная реализация зависит от того, что именно вы пытаетесь сделать — тут уже вам виднее…

= Типичные ошибки при именовании функций, присвоении и инициализации переменных. =

Типичная ошибка, приводящая к вылету:

<code lua>function remove_item(remove_item)
if remove_item~=nil then
alife():release(alife():object(remove_item:id()), true)
return true
end
return false
end</code>

В этом коде агрумент функции совпадает с её именем, и в итоге функция пытается передать функции alife():release вместо указателя на вещь — указатель на саму себя. А так как у функции remove_item нет никакого id, код выпадает с ошибкой:

<code>Arguments : LUA error: ...\s.t.a.l.k.e.r\gamedata\scripts\test.script:486: attempt to call method 'id' (a nil value)</code>

Следует помнить, что Lua — это язык прямого (JIT) компилирования, и он, как любой такой язык не проверяет ошибки при компиляции. Поэтому нужно очень аккуратно раздавать имена переменным и функциям, чтобы избежать подобных ошибок. Данную функцию нужно переписать следующим образом:

<code lua>function remove_item(item_to_remove)
if item_to_remove then
alife():release(alife():object(item_to_remove:id()), true)
return true
end
return false
end</code>

Однажды, отлаживая скрипт, натолкнулся на вот такой код:

<code lua>function hit_callback(npc_id)
if db.storage[npc_id].wounded ≈ nil then
db.storage[npc_id].wounded.wound_manager:hit_callback()
end
end</code>

Казалось бы, всё верно, и значение проверяется перед использованием. Ан нет, скрипт вызывал вылет, причём именно на проверке. Методом тыка было выясено, что nil вызвавший вылет, был не в результате обработки, а был передан фукнции. Это был параметр npc_id.

Пришлось сделать вот так:

<code lua>function hit_callback(npc_id)
if npc_id and db.storage[npc_id].wounded ≈ nil then
db.storage[npc_id].wounded.wound_manager:hit_callback()
end
end</code>

Введя предварительно проверку аргумента npc_id. Вывод — если ставите проверку, старайтесь проверять не только саму функцию, но и вначале — аргумент, который ей передаётся. Мало ли в каком виде он до вас доедет… :)

Касательно именования переменных — не забывайте давать им атрибут local если вы не собираетесь их пользовать во внешних скриптах. Иначе, если попадётся где-то аналогичное имя — будет сбой логики или вылет, помните об этом.

И ещё один совет — для самых начинающих:

Когда пишете скрипты, не забывайте о соблюдении синтаксиса! То есть внимательно и вдумчиво ставьте в концах функций и оснований ключевые слова end — помните, что как отсутствие нужных end’ов, так и наличие лишних приводят к тому, что границы фукций сбиваются, скрипт не парсится обработчиком и вызывает при попытке своего вызова вылет, примерно вот такой:

<code>Arguments : LUA error: ...g\s.t.a.l.k.e.r\gamedata\scripts\bind_stalker.script:75: attempt to index global 'test_main_new' (a nil value)</code>

Для того, чтобы вам проще было следить за синтаксисом и не допускать лишних end’ов, выстраивайте текст скриптов каскадными лесенками:

<code >Начало_Работы
Начало_Внуренней_Функции
Процедуры_Внутреней_Функции
Конец_Внутренней_Функции
Конец_Работы</code>

..и пользуйтесь редакторами с подсветкой синтаксиса, такими как Notepad++ например. В результате каждый уровень вложенности находится на своём отступе. Вы всегда увидите, какую конструкцию нужно закрыть, а какую — нет. Я же например, делаю ещё проще — я, открывая новую функцию, сразу ставлю сразу в её конце, парой строк ниже, end, и потом уже пишу наполняющий её текст с отступами как в примере выше.

И ещё — касательно жизни переменных: не забывайте, что определённые внутри проверок переменные живут только до выхода из проверки. То есть, например:

<code lua>if check == 1 then
local test = true
else
local test = false
end</code>

В данном случае переменная test создастся, но просуществует только до выхода из проверки, и дальше обращение к ней выдаст nil. Для того чтобы этого избежать, определение переменных надо выносить «за скобки» вот так:

<code lua>local test = false; — инитим переменную и задаём сразу ей значение по умолчанию

if check == 1 then
test = true
else
test = false
end</code>

= Смертельные циклы по таблицам =

Если вы строите цикл по таблице следующим образом:

<code lua>for i=1, table.getn(table_name) do</code>

'''То никогда, ни при каких обстоятельствах не используйте внутри этого цикла удаление/добавление строк, т.е:'''

<code lua>table_name[i] = nil</code>

или

<code lua>table.remove(table_name, index)
table.insert(table_name, index)</code>

применительно к таблице по которой гоняете цикл!!! При использовании это приводит к тому, что количество строк в таблице уменьшается, а цикл пытается получить из таблицы строки сверх существующего количества, что в итоге приводит к выходу цикла за отведённый ему диапазон памяти. Результатом будет веер самых разнообразных последствий, самое безобидное из которых это безлоговый вылет на рабочий стол, а серьёзное — сбой в работе а-лайфа с последующим боем сейвов! Тяжесть последствий зависит от того, какие действия вы выполняете внутри цикла кроме удаления строки.

Чтобы избежать подобных ситуаций, стройте циклы по таблице лучше следующим образом:

<code lua>for k, v in pairs(table_name)</code>

А удаление строк внутри них делайте вот так:

<code lua>table_name[k] = nil</code>

Циклы же for i=1, table.getn(table_name) do следует использовать '''только для операций, не изменяющих структуру изменяемой таблицы!'''

----

[[Как писать скрипты, не приводящие к вылетам и бою сейвов (часть 2)|Продолжение во второй части]]

----

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 08:16, 1 сентября 2009 (UTC)

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

Как писать скрипты, не приводящие к вылетам и бою сейвов (часть 2)

2009-09-03T11:06:27Z

Kamikazze:

[[Категория:Статьи участников]]

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Как безопасно использовать коллбэки и таймерные события =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Использование защищённого кода в LUA =

Периодически случаются такие ситуации, когда мы можем получить вылет при проверке аргумента, и не можем его адекватно заизолировать с помощью предварительной проверки на валидность значения. Вот простой пример: когда я отлаживал '''death_callback''' неписей, я периодически сталкивался с тем, что обращение к методу '''smart_terrain_id()''' при смерти непися иногда вызывало вылет

<code>smart_terrain:1143 "attempt to index a nil value"</code>

- хотя это свойство является родным методом объекта, и отсутствовать напрочь никак не может. В итоге я пришёл к выводу, что его просто иногда не успевает отработать движок, так как вылет этот проявлялся в основном в интенсивных боях и совершенно произвольно.

Вот код, в котором происходил вылет:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- вылет происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id)
end
end
end</code>

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

'''pcall (f, arg1, ···)'''

<blockquote>Вызывает функцию f с указанными через запятую аргументами в защищённом режиме. Это означает, что любая ошибка, даже критическая, внутри вызыванной функции, не передаётся наружу - вызавшей подсистеме. Вместо этого '''pcall''' перехватывает ошибку и возвращает код статуса. Первая возвращаемая переменная это сам код, (true или false) и если всё прошло хорошо, он равен true. В этом случае '''pcall''' сразу после статуса возвращает все результаты от работы защищённой им функции. Если же в защищённой функции произошла ошибка, то '''pcall''' вернёт false и затем сообщение об ошибке. (Обратите внимание, обработка ошибки присходит БЕЗ вылета! Вместо вылета вы получите вполне адекватную строку с ошибкой, которую можно вывести в лог для последующей обработки)</blockquote>

Я настоятельно советую пользоваться этой функцией в случаях, когда из коллбэков вызываются сложные комплексные обработки, вроде обработки из менеджера вооружений AI-пака. Это позволяет предотвратить как вылеты, так и зависания обработок, и в итоге позволяет хорошо стабилизировать игру.

Возвращаясь к нашим смарттеррейнам... вот как в итоге я подавил вылет типа smart_terrain:1143 с помощью pcall:

<code lua>--- эта функция пытается проверить св-во smart_terrain_id объекта. Именно её мы вызовем в защищённом режиме.
function prot_smt_td(obj)
if IsStalker(obj) or IsMonster(obj) then
return obj:smart_terrain_id()
else
return 65535
end
end

function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if obj then
local strn_id = 65535 --- предварительно проинитим переменную, на
--- случай если у нас prot_smt_td выдаст ошибку
local result, smt_id = pcall(prot_smt_td,obj) --- вызываем prot_smt_td в защищённом режиме
--- и сразу присваиваем его вывод переменным
if result then --- если pcall выдало true
strn_id = smt_id --- тогда применям полученное значение
end
--- если же обработка выдаст ошибку, то strn_id останется неизменным...
if strn_id ~= 65535 then
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end</code>

В других местах это делается совершенно аналогично. Подробнее об этой и многих других функция для контроля кода, незаслуженно ингорируемых большинством моддеров, можно почитать тут: http://lua-users.org/wiki/FinalizedExceptions - на английском правда, но захотите - разберётесь, там всё просто.

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

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 11:04, 3 сентября 2009 (UTC)

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

Как писать скрипты, не приводящие к вылетам и бою сейвов

2009-09-03T11:05:18Z

Kamikazze: /* Смертельные циклы по таблицам */

Как писать скрипты, не приводящие к вылетам и бою сейвов (часть 2)

2009-09-03T11:04:26Z

Kamikazze:

[[Как писать скрипты, не приводящие к вылетам и бою сейвов|Начало в первой части статьи]]

----

= Как безопасно использовать коллбэки и таймерные события =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Использование защищённого кода в LUA =

Периодически случаются такие ситуации, когда мы можем получить вылет при проверке аргумента, и не можем его адекватно заизолировать с помощью предварительной проверки на валидность значения. Вот простой пример: когда я отлаживал '''death_callback''' неписей, я периодически сталкивался с тем, что обращение к методу '''smart_terrain_id()''' при смерти непися иногда вызывало вылет

<code>smart_terrain:1143 "attempt to index a nil value"</code>

- хотя это свойство является родным методом объекта, и отсутствовать напрочь никак не может. В итоге я пришёл к выводу, что его просто иногда не успевает отработать движок, так как вылет этот проявлялся в основном в интенсивных боях и совершенно произвольно.

Вот код, в котором происходил вылет:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- вылет происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id)
end
end
end</code>

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

'''pcall (f, arg1, ···)'''

<blockquote>Вызывает функцию f с указанными через запятую аргументами в защищённом режиме. Это означает, что любая ошибка, даже критическая, внутри вызыванной функции, не передаётся наружу - вызавшей подсистеме. Вместо этого '''pcall''' перехватывает ошибку и возвращает код статуса. Первая возвращаемая переменная это сам код, (true или false) и если всё прошло хорошо, он равен true. В этом случае '''pcall''' сразу после статуса возвращает все результаты от работы защищённой им функции. Если же в защищённой функции произошла ошибка, то '''pcall''' вернёт false и затем сообщение об ошибке. (Обратите внимание, обработка ошибки присходит БЕЗ вылета! Вместо вылета вы получите вполне адекватную строку с ошибкой, которую можно вывести в лог для последующей обработки)</blockquote>

Я настоятельно советую пользоваться этой функцией в случаях, когда из коллбэков вызываются сложные комплексные обработки, вроде обработки из менеджера вооружений AI-пака. Это позволяет предотвратить как вылеты, так и зависания обработок, и в итоге позволяет хорошо стабилизировать игру.

Возвращаясь к нашим смарттеррейнам... вот как в итоге я подавил вылет типа smart_terrain:1143 с помощью pcall:

<code lua>--- эта функция пытается проверить св-во smart_terrain_id объекта. Именно её мы вызовем в защищённом режиме.
function prot_smt_td(obj)
if IsStalker(obj) or IsMonster(obj) then
return obj:smart_terrain_id()
else
return 65535
end
end

function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if obj then
local strn_id = 65535 --- предварительно проинитим переменную, на
--- случай если у нас prot_smt_td выдаст ошибку
local result, smt_id = pcall(prot_smt_td,obj) --- вызываем prot_smt_td в защищённом режиме
--- и сразу присваиваем его вывод переменным
if result then --- если pcall выдало true
strn_id = smt_id --- тогда применям полученное значение
end
--- если же обработка выдаст ошибку, то strn_id останется неизменным...
if strn_id ~= 65535 then
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end</code>

В других местах это делается совершенно аналогично. Подробнее об этой и многих других функция для контроля кода, незаслуженно ингорируемых большинством моддеров, можно почитать тут: http://lua-users.org/wiki/FinalizedExceptions - на английском правда, но захотите - разберётесь, там всё просто.

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

Циклы же for i=1, table.getn(table_name) do следует использовать '''только для операций, не изменяющих структуру изменяемой таблицы!'''

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 11:04, 3 сентября 2009 (UTC)

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

Как писать скрипты, не приводящие к вылетам и бою сейвов

2009-09-03T11:03:55Z

Kamikazze:

Как писать скрипты, не приводящие к вылетам и бою сейвов

2009-09-01T08:24:59Z

Kamikazze:

[[Категория:Статьи участников]]
= Предисловие =

'''Отладив несколько скриптов на предмет вылетов решил написать это небольшое руководство, чтобы помочь начинающим (да и опытным тоже) скриптописателям избежать потенциальных проблем.'''

Сразу оговорюсь — я программист, поэтому к отладке скриптов подхожу со своей профессиональной точки зрения, и то что я тут изложу вам — сие для программиста есть непреложная истина, и если вы хотите уменьшить количество глюков — старайтесь придерживаться нижеприведённого стиля программирования.

Для начала маленький экскурс в историю. Итак, скрипты в сталкере написаны на языке '''Lua''' — разработали его бразильцы, он очень гибок, легко встраивается в игры и поэтому очень часто используется для написания скриптов любой степени сложности. Так вот, у этого языка и его реализации в игре есть несколько исключительно важных особенностей, которые, при их несоблюдении, будут приводить к вылетам вашего скрипта. Итак:

= Типы данных и проблемы с nil. =

Сначала сделаю маленькое отступление для не знакомых с основами скриптеров, чтобы понятнее было. Итак, в Lua используются следующие логические операторы:

<code>
= оператор присваивания
== сравнение, равно ли значение
≈ сравнение, НЕ равно ли значение
< сравнение, меньше ли значение
> сравнение, больше ли значение
<= сравнение, меньше ли значение или равно
>= сравнение, больше ли значение или равно
and логический оператор И
not логический оператор НЕ
or логический оператор ИЛИ</code>

Всё. Теперь поехали дальше… Язык Lua Изначально создавался для работы с большими строчными базами данных, поэтому ВСЕ виды конструкций в языке — это типы данных, то есть по сути либо переменные, либо константы. Это касается так же и функций! '''Поэтому даже с функциями в Lua можно и нужно обращатся как с переменными.''' Далее. Касательно, собственно «привычных» переменных. '''Обычные переменные в Lua получают свой тип данных только в момент присвоения им значения (запомните, это важно).''' При этом, в Lua есть такой важный и полезный тип данных как nil. nil — Это «пустота», то есть отсутствие какого-либо значения. При этом этот тип используется компилятором скриптов для «сбора мусора», то есть для освобождения занимаемой памяти. Смотрите пример, я объясню подробнее, что это значит:

<code lua>local reminder_count
local exposure_count = 0</code>

Тут у нас 2 локальные переменные, одна из которых просто создана, а вторая — создана и инициализарована. Если сейчас обратиться к переменной reminder_count, считав её значение, то мы получим в качестве значения — nil, то есть пустоту. Если же мы обратимся к переменной exposure_count — то получим, как и ожидали, 0 — так как мы это значение проинициализировали ЗАРАНЕЕ. '''При этом не надо путать nil и 0 — так как 0 — это всё-таки какая-то информация, а вот nil — это её полное отсутствие.''' Так вот, собственно, чем это чревато. Я уже сказал, что nil используется для сбора мусора. Вручную это работает так — когда вам переменная уже не нужна, вы просто пишете:

<code lua>test_variable = nil</code>

И ваша переменная test_variable сотрётся из памяти, и любые ссылки на неё будут выдавать на выходе nil (типа нет такой переменной, «абонент вне зоны действия сети»). Ну так собственно вот, зачем я это всё рассказываю… '''если не определить значение переменной сразу, как это было сделано с переменной reminder_count, то любые попытки обратиться к ней внутри скрипта приведут к вылетам.''' Происходит это следующим образом: допустим, reminder_count — это у нас счётчик напоминаний. То есть мы о чём-то напоминаем игроку текстовыми сообщениями, и помечаем, сколько раз мы это сделали. Определили мы переменную именно так, как в примере выше, то есть не задав ей никакого значения. Значение же её должно присваиваться ниже по коду, после первого оповещения юзера. При этом у нас есть в коде обращение к этой переменной, по которому решается что делать дальше. Выглядит это примерно так:

<code lua>function check_antirad_supplies()

if auto_injection_active then

if antirad_check_delay == nil or game.get_game_time():diffSec(antirad_check_delay) > 60 then

if not db.actor:object(«antirad») and not (use_scientific_kit and db.actor:object(«medkit_scientic»)) then

--обратите внимание сюда
if reminder_count == 0 or reminder_count >= mins_till_next_remind then
--обратите внимание сюда
if use_text then
local news_text = «%c[255,160,160,160]Автоматическая система ввода медицинских
препаратов\\n".."%c[default]Напоминаю: %c[255,230,0,0]
Противорадиационные препараты отстутствуют! %c[default]
Автоматический ввод препаратов невозможен.»
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal",
Frect():set(0,188,83,47), 0, 3000)
end
if use_sounds then
local snd_obj
if use_custom_sounds then
snd_obj = xr_sound.get_safe_sound_object([[HEV\no-anti-rad]])
else
snd_obj = xr_sound.get_safe_sound_object([[device\pda\pda_tip]])
end
if snd_obj then
snd_obj:play_no_feedback(db.actor, sound_object.s2d, 0, vector(), 1.0)
end
end
reminder_count = 1
elseif reminder then
reminder_count = reminder_count + 1
end

else
radiation_warning = true
reminder_count = 0
end
antirad_check_delay = game.get_game_time()
end
end
end</code>

Во время игры всё это скорее всего отработает хорошо, но вот при загрузке… тут могут быть проблемы, так как скрипт при запуске может пролететь ту часть, где переменной reminder_count присваивается значение! В итоге при запуске вышеприведённой функции check_antirad_supplies() нас получится что reminder_count не существует — он равен nil, и в итоге проверка

<code lua>if reminder_count == 0 or reminder_count >= mins_till_next_remind then</code>

выдаст ошибку и приведёт к вылету! Почему? '''Да потому что НЕЛЬЗЯ сравнивать НИЧТО с вещественным значением.''' Именно поэтому, когда вы создаёте новую переменную, вы ОБЯЗАНЫ задать ей значение по умолчанию, даже если вы полностью уверены, что она нигде не будет использована до инициализации. Поверьте — в программировании бывает всё, и запросто может так случиться, что ваша переменная будет использована и спровоцирует вылет.

Простой способ обойти такую кучу проверок и лишних инициализаций — использование or-оператора. пример

<code lua>if (reminder_count or 0) >= mins_till_next_remind then</code>

если переменная равна nil, то выражение вычисляется дальше и получается равным 0, а это уже число и сравнение происходит безболезненно.

Кроме вышеприведённой ситуации, возможен ещё один неприятный момент, связанный с определением переменных и значением nil. Суть его заключается в том, что при присваивании значений или операциями с переменными мы можем получить кучу проблем… покажу конкретнее каких:

== «Смерть» переменных ==

Положим, у нас с reminder_count происходят ещё какие-нибудь занимательные вещи, например мы его значение зачем-нибудь присваиваем другой переменной вот так:

<code lua>antirad_check_delay = reminder_count</code>

Ну и вот, если у нас reminder_count в момент присвоения ещё не имеет никакого значения, то мы получим занимательную штуку — у нас это выражение сработает как

<code lua>antirad_check_delay = nil</code>

В результате чего переменная antirad_check_delay «сдохнет» и будет деловито убрана «сборщиком мусора» из памяти, что моментально приведёт к вылету, когда в дальнейшем какая-то часть кода обратится к значению antirad_check_delay.

== Ошибки деления на 0 ==

Теперь положим что у нас reminder_count используется в каком-нибудь расчёте вот так:

<code lua>antirad_check_delay = exposure_count/reminder_count</code>

Как мы помним, у нас reminder_count не инициализирована, и как следствие равна nil. В итоге мы получим попытку поделить exposure_count на ноль (в нашем случае на nil, что суть одно и то же в нашем случае) и получим «классический» программистский вылет из-за ошибки деления на ноль.

== Ошибки присвоения ==

Предположим что мы написали скрипт, который помогает выбирать оружие при наличии вблизи врагов. И вот, у нас в скрипте есть такой кусок кода, где NPC вынимает из рюкзака оружие:

<code lua>function weapon_manager:set_weapon(wpn)

local enemy = self.npc:best_enemy()
if wpn then
--обратите внимание сюда
self.weapon_id = wpn:id()
--обратите внимание сюда
self:return_items(self.weapon_id)
else
printw(«set_wpn:weapon not exist»)
end
if self.modes.process_mode == "3" and enemy then
for k, v in pairs(self.weapons) do
for i, w in ipairs(v) do
if w.id ≈ self.weapon_id then
local item = level.object_by_id(w.id)
if item and item:parent() and item:parent():id() == self.npc_id then
printw(«set_weapon[%s]:process %s[%s]», self.npc:character_name(), w.id, w.sec)
self:process_item(item)
end
end
end
end
end
if enemy then
self.npc:set_item(object.idle, wpn)
end
self.weapons = nil

end</code>

В помеченном выражении self.weapon_id = wpn:id(), и всё вроде бы отлично, так как стоит проверка if wpn then, однако иногда движок умудряется передать объект функциям некорректно, либо сам скриптер может перепутать при вызове игровой объект с объектом а-лайфа, и присвовение self.weapon_id = wpn:id() либо приравняет self.weapon_id к nil либо сразу приведёт к вылету из-за того что соответствующее свойство объекта не было обнаружено в его классе.

== Как с этим бороться ==

Бороться с такими ситуациями очень просто на самом деле.
Во-первых: ВСЕГДА ИНИЦИАЛИЗИРУЙТЕ ПЕРЕМЕННЫЕ. То есть вот такое описание переменной:

<code>local reminder_count</code>

НЕДОПУСТИМО! ВЫ ОБЯЗАТЕЛЬНО ДОЛЖНЫ ЗАДАТЬ ПЕРЕМЕННОЙ ЗНАЧЕНИЕ!
Если переменная числовая, сделайте это так:

<code>local reminder_count = 0</code>

Если строчная — то сделайте это так:

<code>local reminder_count = ""</code> (получится вместо nil пустая строка)

Если логическая, то так:

<code>local reminder_count = false</code>

В общем, делайте так, как вам удобнее, но ДЕЛАЙТЕ ОБЯЗАТЕЛЬНО!

И во-вторых: ВСЕГДА ПРОВЕРЯЙТЕ ПЕРЕМЕННУЮ ПЕРЕД ИСПОЛЬЗОВАНИЕМ!

То есть в кусках кода, чреватых вылетами (к ним относятся АБСОЛЮТНО ВСЕ части, где идёт работа с вещами или оружием) обязательно вставляйте проверки переменных на nil следующим образом:

<code lua>if wpn and wpn:id() then
self.weapon_id = wpn:id()
end</code>

Тогда сначала выполнится проверка, и если обе переменные имеют значение, то операция отработает, а если один из параметров пуст — то функция просто пропустит этот код. Тут не помешает ещё и проверку вставить на существование self.weapon_id, хотя это наверное уже моя параноя :)

Кстати, что самое дурацкое — ошибки, приведённые выше, часто в лог попадают совершенно непохожим на ошибки скриптов образом. Например, ошибка присвоения из примера 3 приводила к вылету с сообщением «Assertion failed», и поймать её я смог только изучив внимательно предыдущие строки лога, где зафиксировались операции с вещами…

Точно так же, если вы используете ЛЮБЫЕ математические операции например деление (но не только деление, всего остального тоже касается), тоже ОБЯЗАТЕЛЬНО поверяйте переменную. Вот так:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
end</code>

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

<code lua>if wpn and wpn:id() then
self.weapon_id = wpn:id()
end</code>

Или таким:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
end</code>

И у вас в случае некорректного значения компилятор спокойно пропустил этот код, ничего не сделав ни с self.weapon_id (из первого примера), ни с antirad_check_delay (из второго). Однако вам всё-таки нужно, чтобы с ними что-то происходило, даже если проверяемые переменные неверны. Тогда я бы советовал вам дополнить этот обход отработкой нештатной ситуации. Делается это банально просто:

<code lua>if wpn and wpn:id()then
self.weapon_id = wpn:id()
elseif wpn == nil then
--вставьте сюда код, что делать если wpn не существует
elseif wpn:id() == nil then
--а сюда, если wpn:id() не существует
--тут скорее всего перепутан объект, и можно попробовать
--обратиться к wpn.id
end</code>

И для второго случая аналогично:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
else
--а тут что мы сделаем если reminder_count не существует
--я бы сделал например вот так:
antirad_check_delay = exposure_count/1
--и все дела
end</code>

Более конкретная реализация зависит от того, что именно вы пытаетесь сделать — тут уже вам виднее…

= Типичные ошибки при именовании функций, присвоении и инициализации переменных. =

Типичная ошибка, приводящая к вылету:

<code lua>function remove_item(remove_item)
if remove_item~=nil then
alife():release(alife():object(remove_item:id()), true)
return true
end
return false
end</code>

В этом коде агрумент функции совпадает с её именем, и в итоге функция пытается передать функции alife():release вместо указателя на вещь — указатель на саму себя. А так как у функции remove_item нет никакого id, код выпадает с ошибкой:

<code>Arguments : LUA error: ...\s.t.a.l.k.e.r\gamedata\scripts\test.script:486: attempt to call method 'id' (a nil value)</code>

Следует помнить, что Lua — это язык прямого (JIT) компилирования, и он, как любой такой язык не проверяет ошибки при компиляции. Поэтому нужно очень аккуратно раздавать имена переменным и функциям, чтобы избежать подобных ошибок. Данную функцию нужно переписать следующим образом:

<code lua>function remove_item(item_to_remove)
if item_to_remove then
alife():release(alife():object(item_to_remove:id()), true)
return true
end
return false
end</code>

Однажды, отлаживая скрипт, натолкнулся на вот такой код:

<code lua>function hit_callback(npc_id)
if db.storage[npc_id].wounded ≈ nil then
db.storage[npc_id].wounded.wound_manager:hit_callback()
end
end</code>

Казалось бы, всё верно, и значение проверяется перед использованием. Ан нет, скрипт вызывал вылет, причём именно на проверке. Методом тыка было выясено, что nil вызвавший вылет, был не в результате обработки, а был передан фукнции. Это был параметр npc_id.

Пришлось сделать вот так:

<code lua>function hit_callback(npc_id)
if npc_id and db.storage[npc_id].wounded ≈ nil then
db.storage[npc_id].wounded.wound_manager:hit_callback()
end
end</code>

Введя предварительно проверку аргумента npc_id. Вывод — если ставите проверку, старайтесь проверять не только саму функцию, но и вначале — аргумент, который ей передаётся. Мало ли в каком виде он до вас доедет… :)

Касательно именования переменных — не забывайте давать им атрибут local если вы не собираетесь их пользовать во внешних скриптах. Иначе, если попадётся где-то аналогичное имя — будет сбой логики или вылет, помните об этом.

И ещё один совет — для самых начинающих:

Когда пишете скрипты, не забывайте о соблюдении синтаксиса! То есть внимательно и вдумчиво ставьте в концах функций и оснований ключевые слова end — помните, что как отсутствие нужных end’ов, так и наличие лишних приводят к тому, что границы фукций сбиваются, скрипт не парсится обработчиком и вызывает при попытке своего вызова вылет, примерно вот такой:

<code>Arguments : LUA error: ...g\s.t.a.l.k.e.r\gamedata\scripts\bind_stalker.script:75: attempt to index global 'test_main_new' (a nil value)</code>

Для того, чтобы вам проще было следить за синтаксисом и не допускать лишних end’ов, выстраивайте текст скриптов каскадными лесенками:

<code >Начало_Работы
Начало_Внуренней_Функции
Процедуры_Внутреней_Функции
Конец_Внутренней_Функции
Конец_Работы</code>

..и пользуйтесь редакторами с подсветкой синтаксиса, такими как Notepad++ например. В результате каждый уровень вложенности находится на своём отступе. Вы всегда увидите, какую конструкцию нужно закрыть, а какую — нет. Я же например, делаю ещё проще — я, открывая новую функцию, сразу ставлю сразу в её конце, парой строк ниже, end, и потом уже пишу наполняющий её текст с отступами как в примере выше.

И ещё — касательно жизни переменных: не забывайте, что определённые внутри проверок переменные живут только до выхода из проверки. То есть, например:

<code lua>if check == 1 then
local test = true
else
local test = false
end</code>

В данном случае переменная test создастся, но просуществует только до выхода из проверки, и дальше обращение к ней выдаст nil. Для того чтобы этого избежать, определение переменных надо выносить «за скобки» вот так:

<code lua>local test = false; — инитим переменную и задаём сразу ей значение по умолчанию

if check == 1 then
test = true
else
test = false
end</code>

= Смертельные циклы по таблицам =

Если вы строите цикл по таблице следующим образом:

<code lua>for i=1, table.getn(table_name) do</code>

'''То никогда, ни при каких обстоятельствах не используйте внутри этого цикла удаление/добавление строк, т.е:'''

<code lua>table_name[i] = nil</code>

или

<code lua>table.remove(table_name, index)
table.insert(table_name, index)</code>

применительно к таблице по которой гоняете цикл!!! При использовании это приводит к тому, что количество строк в таблице уменьшается, а цикл пытается получить из таблицы строки сверх существующего количества, что в итоге приводит к выходу цикла за отведённый ему диапазон памяти. Результатом будет веер самых разнообразных последствий, самое безобидное из которых это безлоговый вылет на рабочий стол, а серьёзное — сбой в работе а-лайфа с последующим боем сейвов! Тяжесть последствий зависит от того, какие действия вы выполняете внутри цикла кроме удаления строки.

Чтобы избежать подобных ситуаций, стройте циклы по таблице лучше следующим образом:

<code lua>for k, v in pairs(table_name)</code>

А удаление строк внутри них делайте вот так:

<code lua>table_name[k] = nil</code>

Циклы же for i=1, table.getn(table_name) do следует использовать '''только для операций, не изменяющих структуру изменяемой таблицы!'''

= Как безопасно использовать коллбэки и таймерные события =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Использование защищённого кода в LUA =

Периодически случаются такие ситуации, когда мы можем получить вылет при проверке аргумента, и не можем его адекватно заизолировать с помощью предварительной проверки на валидность значения. Вот простой пример: когда я отлаживал '''death_callback''' неписей, я периодически сталкивался с тем, что обращение к методу '''smart_terrain_id()''' при смерти непися иногда вызывало вылет

<code>smart_terrain:1143 "attempt to index a nil value"</code>

- хотя это свойство является родным методом объекта, и отсутствовать напрочь никак не может. В итоге я пришёл к выводу, что его просто иногда не успевает отработать движок, так как вылет этот проявлялся в основном в интенсивных боях и совершенно произвольно.

Вот код, в котором происходил вылет:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- вылет происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id)
end
end
end</code>

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

'''pcall (f, arg1, ···)'''

<blockquote>Вызывает функцию f с указанными через запятую аргументами в защищённом режиме. Это означает, что любая ошибка, даже критическая, внутри вызыванной функции, не передаётся наружу - вызавшей подсистеме. Вместо этого '''pcall''' перехватывает ошибку и возвращает код статуса. Первая возвращаемая переменная это сам код, (true или false) и если всё прошло хорошо, он равен true. В этом случае '''pcall''' сразу после статуса возвращает все результаты от работы защищённой им функции. Если же в защищённой функции произошла ошибка, то '''pcall''' вернёт false и затем сообщение об ошибке. (Обратите внимание, обработка ошибки присходит БЕЗ вылета! Вместо вылета вы получите вполне адекватную строку с ошибкой, которую можно вывести в лог для последующей обработки)</blockquote>

Я настоятельно советую пользоваться этой функцией в случаях, когда из коллбэков вызываются сложные комплексные обработки, вроде обработки из менеджера вооружений AI-пака. Это позволяет предотвратить как вылеты, так и зависания обработок, и в итоге позволяет хорошо стабилизировать игру.

Возвращаясь к нашим смарттеррейнам... вот как в итоге я подавил вылет типа smart_terrain:1143 с помощью pcall:

<code lua>--- эта функция пытается проверить св-во smart_terrain_id объекта. Именно её мы вызовем в защищённом режиме.
function prot_smt_td(obj)
if IsStalker(obj) or IsMonster(obj) then
return obj:smart_terrain_id()
else
return 65535
end
end

function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if obj then
local strn_id = 65535 --- предварительно проинитим переменную, на
--- случай если у нас prot_smt_td выдаст ошибку
local result, smt_id = pcall(prot_smt_td,obj) --- вызываем prot_smt_td в защищённом режиме
--- и сразу присваиваем его вывод переменным
if result then --- если pcall выдало true
strn_id = smt_id --- тогда применям полученное значение
end
--- если же обработка выдаст ошибку, то strn_id останется неизменным...
if strn_id ~= 65535 then
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end</code>

В других местах это делается совершенно аналогично. Подробнее об этой и многих других функция для контроля кода, незаслуженно ингорируемых большинством моддеров, можно почитать тут: http://lua-users.org/wiki/FinalizedExceptions - на английском правда, но захотите - разберётесь, там всё просто.

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

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 08:16, 1 сентября 2009 (UTC)

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

Участник:Kamikazze

2009-09-01T08:22:27Z

Kamikazze:

Программист, скриптер, отладчик.
Работаю над модом OGS Evolution, ознакомится с которым можно на его родном сайте: http://ogse.ru
---------
Связаться со мной можно через личку на том же сайте или по номеру ICQ: 339-623-395

Участник:Kamikazze

2009-09-01T08:21:53Z

Kamikazze:

Как писать скрипты, не приводящие к вылетам и бою сейвов

2009-09-01T08:16:40Z

Kamikazze: дополнение

[[Категория:Статьи участников]]
= Предисловие =

'''Отладив несколько скриптов на предмет вылетов решил написать это небольшое руководство, чтобы помочь начинающим (да и опытным тоже) скриптописателям избежать потенциальных проблем.'''

Сразу оговорюсь — я программист, поэтому к отладке скриптов подхожу со своей профессиональной точки зрения, и то что я тут изложу вам — сие для программиста есть непреложная истина, и если вы хотите уменьшить количество глюков — старайтесь придерживаться нижеприведённого стиля программирования.

Для начала маленький экскурс в историю. Итак, скрипты в сталкере написаны на языке '''Lua''' — разработали его бразильцы, он очень гибок, легко встраивается в игры и поэтому очень часто используется для написания скриптов любой степени сложности. Так вот, у этого языка и его реализации в игре есть несколько исключительно важных особенностей, которые, при их несоблюдении, будут приводить к вылетам вашего скрипта. Итак:

= Особенность первая. Типы данных и проблемы с nil. =

Сначала сделаю маленькое отступление для не знакомых с основами скриптеров, чтобы понятнее было. Итак, в Lua используются следующие логические операторы:

<code>
= оператор присваивания
== сравнение, равно ли значение
≈ сравнение, НЕ равно ли значение
< сравнение, меньше ли значение
> сравнение, больше ли значение
<= сравнение, меньше ли значение или равно
>= сравнение, больше ли значение или равно
and логический оператор И
not логический оператор НЕ
or логический оператор ИЛИ</code>

Всё. Теперь поехали дальше… Язык Lua Изначально создавался для работы с большими строчными базами данных, поэтому ВСЕ виды конструкций в языке — это типы данных, то есть по сути либо переменные, либо константы. Это касается так же и функций! '''Поэтому даже с функциями в Lua можно и нужно обращатся как с переменными.''' Далее. Касательно, собственно «привычных» переменных. '''Обычные переменные в Lua получают свой тип данных только в момент присвоения им значения (запомните, это важно).''' При этом, в Lua есть такой важный и полезный тип данных как nil. nil — Это «пустота», то есть отсутствие какого-либо значения. При этом этот тип используется компилятором скриптов для «сбора мусора», то есть для освобождения занимаемой памяти. Смотрите пример, я объясню подробнее, что это значит:

<code lua>local reminder_count
local exposure_count = 0</code>

Тут у нас 2 локальные переменные, одна из которых просто создана, а вторая — создана и инициализарована. Если сейчас обратиться к переменной reminder_count, считав её значение, то мы получим в качестве значения — nil, то есть пустоту. Если же мы обратимся к переменной exposure_count — то получим, как и ожидали, 0 — так как мы это значение проинициализировали ЗАРАНЕЕ. '''При этом не надо путать nil и 0 — так как 0 — это всё-таки какая-то информация, а вот nil — это её полное отсутствие.''' Так вот, собственно, чем это чревато. Я уже сказал, что nil используется для сбора мусора. Вручную это работает так — когда вам переменная уже не нужна, вы просто пишете:

<code lua>test_variable = nil</code>

И ваша переменная test_variable сотрётся из памяти, и любые ссылки на неё будут выдавать на выходе nil (типа нет такой переменной, «абонент вне зоны действия сети»). Ну так собственно вот, зачем я это всё рассказываю… '''если не определить значение переменной сразу, как это было сделано с переменной reminder_count, то любые попытки обратиться к ней внутри скрипта приведут к вылетам.''' Происходит это следующим образом: допустим, reminder_count — это у нас счётчик напоминаний. То есть мы о чём-то напоминаем игроку текстовыми сообщениями, и помечаем, сколько раз мы это сделали. Определили мы переменную именно так, как в примере выше, то есть не задав ей никакого значения. Значение же её должно присваиваться ниже по коду, после первого оповещения юзера. При этом у нас есть в коде обращение к этой переменной, по которому решается что делать дальше. Выглядит это примерно так:

<code lua>function check_antirad_supplies()

if auto_injection_active then

if antirad_check_delay == nil or game.get_game_time():diffSec(antirad_check_delay) > 60 then

if not db.actor:object(«antirad») and not (use_scientific_kit and db.actor:object(«medkit_scientic»)) then

--обратите внимание сюда
if reminder_count == 0 or reminder_count >= mins_till_next_remind then
--обратите внимание сюда
if use_text then
local news_text = «%c[255,160,160,160]Автоматическая система ввода медицинских
препаратов\\n".."%c[default]Напоминаю: %c[255,230,0,0]
Противорадиационные препараты отстутствуют! %c[default]
Автоматический ввод препаратов невозможен.»
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal",
Frect():set(0,188,83,47), 0, 3000)
end
if use_sounds then
local snd_obj
if use_custom_sounds then
snd_obj = xr_sound.get_safe_sound_object([[HEV\no-anti-rad]])
else
snd_obj = xr_sound.get_safe_sound_object([[device\pda\pda_tip]])
end
if snd_obj then
snd_obj:play_no_feedback(db.actor, sound_object.s2d, 0, vector(), 1.0)
end
end
reminder_count = 1
elseif reminder then
reminder_count = reminder_count + 1
end

else
radiation_warning = true
reminder_count = 0
end
antirad_check_delay = game.get_game_time()
end
end
end</code>

Во время игры всё это скорее всего отработает хорошо, но вот при загрузке… тут могут быть проблемы, так как скрипт при запуске может пролететь ту часть, где переменной reminder_count присваивается значение! В итоге при запуске вышеприведённой функции check_antirad_supplies() нас получится что reminder_count не существует — он равен nil, и в итоге проверка

<code lua>if reminder_count == 0 or reminder_count >= mins_till_next_remind then</code>

выдаст ошибку и приведёт к вылету! Почему? '''Да потому что НЕЛЬЗЯ сравнивать НИЧТО с вещественным значением.''' Именно поэтому, когда вы создаёте новую переменную, вы ОБЯЗАНЫ задать ей значение по умолчанию, даже если вы полностью уверены, что она нигде не будет использована до инициализации. Поверьте — в программировании бывает всё, и запросто может так случиться, что ваша переменная будет использована и спровоцирует вылет.

Простой способ обойти такую кучу проверок и лишних инициализаций — использование or-оператора. пример

<code lua>if (reminder_count or 0) >= mins_till_next_remind then</code>

если переменная равна nil, то выражение вычисляется дальше и получается равным 0, а это уже число и сравнение происходит безболезненно.

Кроме вышеприведённой ситуации, возможен ещё один неприятный момент, связанный с определением переменных и значением nil. Суть его заключается в том, что при присваивании значений или операциями с переменными мы можем получить кучу проблем… покажу конкретнее каких:

== «Смерть» переменных ==

Положим, у нас с reminder_count происходят ещё какие-нибудь занимательные вещи, например мы его значение зачем-нибудь присваиваем другой переменной вот так:

<code lua>antirad_check_delay = reminder_count</code>

Ну и вот, если у нас reminder_count в момент присвоения ещё не имеет никакого значения, то мы получим занимательную штуку — у нас это выражение сработает как

<code lua>antirad_check_delay = nil</code>

В результате чего переменная antirad_check_delay «сдохнет» и будет деловито убрана «сборщиком мусора» из памяти, что моментально приведёт к вылету, когда в дальнейшем какая-то часть кода обратится к значению antirad_check_delay.

== Ошибки деления на 0 ==

Теперь положим что у нас reminder_count используется в каком-нибудь расчёте вот так:

<code lua>antirad_check_delay = exposure_count/reminder_count</code>

Как мы помним, у нас reminder_count не инициализирована, и как следствие равна nil. В итоге мы получим попытку поделить exposure_count на ноль (в нашем случае на nil, что суть одно и то же в нашем случае) и получим «классический» программистский вылет из-за ошибки деления на ноль.

== Ошибки присвоения ==

Предположим что мы написали скрипт, который помогает выбирать оружие при наличии вблизи врагов. И вот, у нас в скрипте есть такой кусок кода, где NPC вынимает из рюкзака оружие:

<code lua>function weapon_manager:set_weapon(wpn)

local enemy = self.npc:best_enemy()
if wpn then
--обратите внимание сюда
self.weapon_id = wpn:id()
--обратите внимание сюда
self:return_items(self.weapon_id)
else
printw(«set_wpn:weapon not exist»)
end
if self.modes.process_mode == "3" and enemy then
for k, v in pairs(self.weapons) do
for i, w in ipairs(v) do
if w.id ≈ self.weapon_id then
local item = level.object_by_id(w.id)
if item and item:parent() and item:parent():id() == self.npc_id then
printw(«set_weapon[%s]:process %s[%s]», self.npc:character_name(), w.id, w.sec)
self:process_item(item)
end
end
end
end
end
if enemy then
self.npc:set_item(object.idle, wpn)
end
self.weapons = nil

end</code>

В помеченном выражении self.weapon_id = wpn:id(), и всё вроде бы отлично, так как стоит проверка if wpn then, однако иногда движок умудряется передать объект функциям некорректно, либо сам скриптер может перепутать при вызове игровой объект с объектом а-лайфа, и присвовение self.weapon_id = wpn:id() либо приравняет self.weapon_id к nil либо сразу приведёт к вылету из-за того что соответствующее свойство объекта не было обнаружено в его классе.

== Как с этим бороться ==

Бороться с такими ситуациями очень просто на самом деле.
Во-первых: ВСЕГДА ИНИЦИАЛИЗИРУЙТЕ ПЕРЕМЕННЫЕ. То есть вот такое описание переменной:

<code>local reminder_count</code>

НЕДОПУСТИМО! ВЫ ОБЯЗАТЕЛЬНО ДОЛЖНЫ ЗАДАТЬ ПЕРЕМЕННОЙ ЗНАЧЕНИЕ!
Если переменная числовая, сделайте это так:

<code>local reminder_count = 0</code>

Если строчная — то сделайте это так:

<code>local reminder_count = ""</code> (получится вместо nil пустая строка)

Если логическая, то так:

<code>local reminder_count = false</code>

В общем, делайте так, как вам удобнее, но ДЕЛАЙТЕ ОБЯЗАТЕЛЬНО!

И во-вторых: ВСЕГДА ПРОВЕРЯЙТЕ ПЕРЕМЕННУЮ ПЕРЕД ИСПОЛЬЗОВАНИЕМ!

То есть в кусках кода, чреватых вылетами (к ним относятся АБСОЛЮТНО ВСЕ части, где идёт работа с вещами или оружием) обязательно вставляйте проверки переменных на nil следующим образом:

<code lua>if wpn and wpn:id() then
self.weapon_id = wpn:id()
end</code>

Тогда сначала выполнится проверка, и если обе переменные имеют значение, то операция отработает, а если один из параметров пуст — то функция просто пропустит этот код. Тут не помешает ещё и проверку вставить на существование self.weapon_id, хотя это наверное уже моя параноя :)

Кстати, что самое дурацкое — ошибки, приведённые выше, часто в лог попадают совершенно непохожим на ошибки скриптов образом. Например, ошибка присвоения из примера 3 приводила к вылету с сообщением «Assertion failed», и поймать её я смог только изучив внимательно предыдущие строки лога, где зафиксировались операции с вещами…

Точно так же, если вы используете ЛЮБЫЕ математические операции например деление (но не только деление, всего остального тоже касается), тоже ОБЯЗАТЕЛЬНО поверяйте переменную. Вот так:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
end</code>

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

<code lua>if wpn and wpn:id() then
self.weapon_id = wpn:id()
end</code>

Или таким:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
end</code>

И у вас в случае некорректного значения компилятор спокойно пропустил этот код, ничего не сделав ни с self.weapon_id (из первого примера), ни с antirad_check_delay (из второго). Однако вам всё-таки нужно, чтобы с ними что-то происходило, даже если проверяемые переменные неверны. Тогда я бы советовал вам дополнить этот обход отработкой нештатной ситуации. Делается это банально просто:

<code lua>if wpn and wpn:id()then
self.weapon_id = wpn:id()
elseif wpn == nil then
--вставьте сюда код, что делать если wpn не существует
elseif wpn:id() == nil then
--а сюда, если wpn:id() не существует
--тут скорее всего перепутан объект, и можно попробовать
--обратиться к wpn.id
end</code>

И для второго случая аналогично:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
else
--а тут что мы сделаем если reminder_count не существует
--я бы сделал например вот так:
antirad_check_delay = exposure_count/1
--и все дела
end</code>

Более конкретная реализация зависит от того, что именно вы пытаетесь сделать — тут уже вам виднее…

= Особенность вторая. Типичные ошибки при именовании функций, присвоении и инициализации переменных. =

Типичная ошибка, приводящая к вылету:

<code lua>function remove_item(remove_item)
if remove_item~=nil then
alife():release(alife():object(remove_item:id()), true)
return true
end
return false
end</code>

В этом коде агрумент функции совпадает с её именем, и в итоге функция пытается передать функции alife():release вместо указателя на вещь — указатель на саму себя. А так как у функции remove_item нет никакого id, код выпадает с ошибкой:

<code>Arguments : LUA error: ...\s.t.a.l.k.e.r\gamedata\scripts\test.script:486: attempt to call method 'id' (a nil value)</code>

Следует помнить, что Lua — это язык прямого (JIT) компилирования, и он, как любой такой язык не проверяет ошибки при компиляции. Поэтому нужно очень аккуратно раздавать имена переменным и функциям, чтобы избежать подобных ошибок. Данную функцию нужно переписать следующим образом:

<code lua>function remove_item(item_to_remove)
if item_to_remove then
alife():release(alife():object(item_to_remove:id()), true)
return true
end
return false
end</code>

Однажды, отлаживая скрипт, натолкнулся на вот такой код:

<code lua>function hit_callback(npc_id)
if db.storage[npc_id].wounded ≈ nil then
db.storage[npc_id].wounded.wound_manager:hit_callback()
end
end</code>

Казалось бы, всё верно, и значение проверяется перед использованием. Ан нет, скрипт вызывал вылет, причём именно на проверке. Методом тыка было выясено, что nil вызвавший вылет, был не в результате обработки, а был передан фукнции. Это был параметр npc_id.

Пришлось сделать вот так:

<code lua>function hit_callback(npc_id)
if npc_id and db.storage[npc_id].wounded ≈ nil then
db.storage[npc_id].wounded.wound_manager:hit_callback()
end
end</code>

Введя предварительно проверку аргумента npc_id. Вывод — если ставите проверку, старайтесь проверять не только саму функцию, но и вначале — аргумент, который ей передаётся. Мало ли в каком виде он до вас доедет… :)

Касательно именования переменных — не забывайте давать им атрибут local если вы не собираетесь их пользовать во внешних скриптах. Иначе, если попадётся где-то аналогичное имя — будет сбой логики или вылет, помните об этом.

И ещё один совет — для самых начинающих:

Когда пишете скрипты, не забывайте о соблюдении синтаксиса! То есть внимательно и вдумчиво ставьте в концах функций и оснований ключевые слова end — помните, что как отсутствие нужных end’ов, так и наличие лишних приводят к тому, что границы фукций сбиваются, скрипт не парсится обработчиком и вызывает при попытке своего вызова вылет, примерно вот такой:

<code>Arguments : LUA error: ...g\s.t.a.l.k.e.r\gamedata\scripts\bind_stalker.script:75: attempt to index global 'test_main_new' (a nil value)</code>

Для того, чтобы вам проще было следить за синтаксисом и не допускать лишних end’ов, выстраивайте текст скриптов каскадными лесенками:

<code >Начало_Работы
Начало_Внуренней_Функции
Процедуры_Внутреней_Функции
Конец_Внутренней_Функции
Конец_Работы</code>

..и пользуйтесь редакторами с подсветкой синтаксиса, такими как Notepad++ например. В результате каждый уровень вложенности находится на своём отступе. Вы всегда увидите, какую конструкцию нужно закрыть, а какую — нет. Я же например, делаю ещё проще — я, открывая новую функцию, сразу ставлю сразу в её конце, парой строк ниже, end, и потом уже пишу наполняющий её текст с отступами как в примере выше.

И ещё — касательно жизни переменных: не забывайте, что определённые внутри проверок переменные живут только до выхода из проверки. То есть, например:

<code lua>if check == 1 then
local test = true
else
local test = false
end</code>

В данном случае переменная test создастся, но просуществует только до выхода из проверки, и дальше обращение к ней выдаст nil. Для того чтобы этого избежать, определение переменных надо выносить «за скобки» вот так:

<code lua>local test = false; — инитим переменную и задаём сразу ей значение по умолчанию

if check == 1 then
test = true
else
test = false
end</code>

= Особенность третья. Смертельные циклы по таблицам. =

Если вы строите цикл по таблице следующим образом:

<code lua>for i=1, table.getn(table_name) do</code>

'''То никогда, ни при каких обстоятельствах не используйте внутри этого цикла удаление/добавление строк, т.е:'''

<code lua>table_name[i] = nil</code>

или

<code lua>table.remove(table_name, index)
table.insert(table_name, index)</code>

применительно к таблице по которой гоняете цикл!!! При использовании это приводит к тому, что количество строк в таблице уменьшается, а цикл пытается получить из таблицы строки сверх существующего количества, что в итоге приводит к выходу цикла за отведённый ему диапазон памяти. Результатом будет веер самых разнообразных последствий, самое безобидное из которых это безлоговый вылет на рабочий стол, а серьёзное — сбой в работе а-лайфа с последующим боем сейвов! Тяжесть последствий зависит от того, какие действия вы выполняете внутри цикла кроме удаления строки.

Чтобы избежать подобных ситуаций, стройте циклы по таблице лучше следующим образом:

<code lua>for k, v in pairs(table_name)</code>

А удаление строк внутри них делайте вот так:

<code lua>table_name[k] = nil</code>

Циклы же for i=1, table.getn(table_name) do следует использовать '''только для операций, не изменяющих структуру изменяемой таблицы!'''

= Особенность четвёртая. Как безопасно использовать коллбэки и таймерные события. =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Использование защищённого кода в LUA =

Периодически случаются такие ситуации, когда мы можем получить вылет при проверке аргумента, и не можем его адекватно заизолировать с помощью предварительной проверки на валидность значения. Вот простой пример: когда я отлаживал '''death_callback''' неписей, я периодически сталкивался с тем, что обращение к методу '''smart_terrain_id()''' при смерти непися иногда вызывало вылет

<code>smart_terrain:1143 "attempt to index a nil value"</code>

- хотя это свойство является родным методом объекта, и отсутствовать напрочь никак не может. В итоге я пришёл к выводу, что его просто иногда не успевает отработать движок, так как вылет этот проявлялся в основном в интенсивных боях и совершенно произвольно.

Вот код, в котором происходил вылет:

<code lua>function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )

local sim = alife()

if sim then
local obj = sim:object( obj_id )
local strn_id = obj:smart_terrain_id() --- вылет происходит тут

if strn_id ~= 65535 then
sim:object( strn_id ).gulag:clear_dead(obj_id)
end
end
end</code>

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

'''pcall (f, arg1, ···)'''

<blockquote>Вызывает функцию f с указанными через запятую аргументами в защищённом режиме. Это означает, что любая ошибка, даже критическая, внутри вызыванной функции, не передаётся наружу - вызавшей подсистеме. Вместо этого '''pcall''' перехватывает ошибку и возвращает код статуса. Первая возвращаемая переменная это сам код, (true или false) и если всё прошло хорошо, он равен true. В этом случае '''pcall''' сразу после статуса возвращает все результаты от работы защищённой им функции. Если же в защищённой функции произошла ошибка, то '''pcall''' вернёт false и затем сообщение об ошибке. (Обратите внимание, обработка ошибки присходит БЕЗ вылета! Вместо вылета вы получите вполне адекватную строку с ошибкой, которую можно вывести в лог для последующей обработки)</blockquote>

Я настоятельно советую пользоваться этой функцией в случаях, когда из коллбэков вызываются сложные комплексные обработки, вроде обработки из менеджера вооружений AI-пака. Это позволяет предотвратить как вылеты, так и зависания обработок, и в итоге позволяет хорошо стабилизировать игру.

Возвращаясь к нашим смарттеррейнам... вот как в итоге я подавил вылет типа smart_terrain:1143 с помощью pcall:

<code lua>--- эта функция пытается проверить св-во smart_terrain_id объекта. Именно её мы вызовем в защищённом режиме.
function prot_smt_td(obj)
if IsStalker(obj) or IsMonster(obj) then
return obj:smart_terrain_id()
else
return 65535
end
end

function on_death( obj_id )
-- printf( "on_death obj_id=%d", obj_id )
local sim = alife()
if sim then
local obj = sim:object( obj_id )
if obj then
local strn_id = 65535 --- предварительно проинитим переменную, на
--- случай если у нас prot_smt_td выдаст ошибку
local result, smt_id = pcall(prot_smt_td,obj) --- вызываем prot_smt_td в защищённом режиме
--- и сразу присваиваем его вывод переменным
if result then --- если pcall выдало true
strn_id = smt_id --- тогда применям полученное значение
end
--- если же обработка выдаст ошибку, то strn_id останется неизменным...
if strn_id ~= 65535 then
sim:object(strn_id).gulag:clear_dead(obj_id)
end
end
end
end</code>

В других местах это делается совершенно аналогично. Подробнее об этой и многих других функция для контроля кода, незаслуженно ингорируемых большинством моддеров, можно почитать тут: http://lua-users.org/wiki/FinalizedExceptions - на английском правда, но захотите - разберётесь, там всё просто.

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

--[[Участник:Kamikazze|KamikaZze (OGSE Team)]] 08:16, 1 сентября 2009 (UTC)

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

Как писать скрипты, не приводящие к вылетам и бою сейвов

2009-08-25T10:05:33Z

Kamikazze: /* Ошибки присвоения */

[[Категория:Статьи участников]]
= Предисловие =

'''Отладив несколько скриптов на предмет вылетов решил написать это небольшое руководство, чтобы помочь начинающим (да и опытным тоже) скриптописателям избежать потенциальных проблем.'''

Сразу оговорюсь — я программист, поэтому к отладке скриптов подхожу со своей профессиональной точки зрения, и то что я тут изложу вам — сие для программиста есть непреложная истина, и если вы хотите уменьшить количество глюков — старайтесь придерживаться нижеприведённого стиля программирования.

Для начала маленький экскурс в историю. Итак, скрипты в сталкере написаны на языке '''Lua''' — разработали его бразильцы, он очень гибок, легко встраивается в игры и поэтому очень часто используется для написания скриптов любой степени сложности. Так вот, у этого языка и его реализации в игре есть несколько исключительно важных особенностей, которые, при их несоблюдении, будут приводить к вылетам вашего скрипта. Итак:

= Особенность первая. Типы данных и проблемы с nil. =

Сначала сделаю маленькое отступление для не знакомых с основами скриптеров, чтобы понятнее было. Итак, в Lua используются следующие логические операторы:

<code>
= оператор присваивания
== сравнение, равно ли значение
≈ сравнение, НЕ равно ли значение
< сравнение, меньше ли значение
> сравнение, больше ли значение
<= сравнение, меньше ли значение или равно
>= сравнение, больше ли значение или равно
and логический оператор И
not логический оператор НЕ
or логический оператор ИЛИ</code>

Всё. Теперь поехали дальше… Язык Lua Изначально создавался для работы с большими строчными базами данных, поэтому ВСЕ виды конструкций в языке — это типы данных, то есть по сути либо переменные, либо константы. Это касается так же и функций! '''Поэтому даже с функциями в Lua можно и нужно обращатся как с переменными.''' Далее. Касательно, собственно «привычных» переменных. '''Обычные переменные в Lua получают свой тип данных только в момент присвоения им значения (запомните, это важно).''' При этом, в Lua есть такой важный и полезный тип данных как nil. nil — Это «пустота», то есть отсутствие какого-либо значения. При этом этот тип используется компилятором скриптов для «сбора мусора», то есть для освобождения занимаемой памяти. Смотрите пример, я объясню подробнее, что это значит:

<code lua>local reminder_count
local exposure_count = 0</code>

Тут у нас 2 локальные переменные, одна из которых просто создана, а вторая — создана и инициализарована. Если сейчас обратиться к переменной reminder_count, считав её значение, то мы получим в качестве значения — nil, то есть пустоту. Если же мы обратимся к переменной exposure_count — то получим, как и ожидали, 0 — так как мы это значение проинициализировали ЗАРАНЕЕ. '''При этом не надо путать nil и 0 — так как 0 — это всё-таки какая-то информация, а вот nil — это её полное отсутствие.''' Так вот, собственно, чем это чревато. Я уже сказал, что nil используется для сбора мусора. Вручную это работает так — когда вам переменная уже не нужна, вы просто пишете:

<code lua>test_variable = nil</code>

И ваша переменная test_variable сотрётся из памяти, и любые ссылки на неё будут выдавать на выходе nil (типа нет такой переменной, «абонент вне зоны действия сети»). Ну так собственно вот, зачем я это всё рассказываю… '''если не определить значение переменной сразу, как это было сделано с переменной reminder_count, то любые попытки обратиться к ней внутри скрипта приведут к вылетам.''' Происходит это следующим образом: допустим, reminder_count — это у нас счётчик напоминаний. То есть мы о чём-то напоминаем игроку текстовыми сообщениями, и помечаем, сколько раз мы это сделали. Определили мы переменную именно так, как в примере выше, то есть не задав ей никакого значения. Значение же её должно присваиваться ниже по коду, после первого оповещения юзера. При этом у нас есть в коде обращение к этой переменной, по которому решается что делать дальше. Выглядит это примерно так:

<code lua>function check_antirad_supplies()

if auto_injection_active then

if antirad_check_delay == nil or game.get_game_time():diffSec(antirad_check_delay) > 60 then

if not db.actor:object(«antirad») and not (use_scientific_kit and db.actor:object(«medkit_scientic»)) then

--обратите внимание сюда
if reminder_count == 0 or reminder_count >= mins_till_next_remind then
--обратите внимание сюда
if use_text then
local news_text = «%c[255,160,160,160]Автоматическая система ввода медицинских
препаратов\\n".."%c[default]Напоминаю: %c[255,230,0,0]
Противорадиационные препараты отстутствуют! %c[default]
Автоматический ввод препаратов невозможен.»
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal",
Frect():set(0,188,83,47), 0, 3000)
end
if use_sounds then
local snd_obj
if use_custom_sounds then
snd_obj = xr_sound.get_safe_sound_object([[HEV\no-anti-rad]])
else
snd_obj = xr_sound.get_safe_sound_object([[device\pda\pda_tip]])
end
if snd_obj then
snd_obj:play_no_feedback(db.actor, sound_object.s2d, 0, vector(), 1.0)
end
end
reminder_count = 1
elseif reminder then
reminder_count = reminder_count + 1
end

else
radiation_warning = true
reminder_count = 0
end
antirad_check_delay = game.get_game_time()
end
end
end</code>

Во время игры всё это скорее всего отработает хорошо, но вот при загрузке… тут могут быть проблемы, так как скрипт при запуске может пролететь ту часть, где переменной reminder_count присваивается значение! В итоге при запуске вышеприведённой функции check_antirad_supplies() нас получится что reminder_count не существует — он равен nil, и в итоге проверка

<code lua>if reminder_count == 0 or reminder_count >= mins_till_next_remind then</code>

выдаст ошибку и приведёт к вылету! Почему? '''Да потому что НЕЛЬЗЯ сравнивать НИЧТО с вещественным значением.''' Именно поэтому, когда вы создаёте новую переменную, вы ОБЯЗАНЫ задать ей значение по умолчанию, даже если вы полностью уверены, что она нигде не будет использована до инициализации. Поверьте — в программировании бывает всё, и запросто может так случиться, что ваша переменная будет использована и спровоцирует вылет.

Простой способ обойти такую кучу проверок и лишних инициализаций — использование or-оператора. пример

<code lua>if (reminder_count or 0) >= mins_till_next_remind then</code>

если переменная равна nil, то выражение вычисляется дальше и получается равным 0, а это уже число и сравнение происходит безболезненно.

Кроме вышеприведённой ситуации, возможен ещё один неприятный момент, связанный с определением переменных и значением nil. Суть его заключается в том, что при присваивании значений или операциями с переменными мы можем получить кучу проблем… покажу конкретнее каких:

== «Смерть» переменных ==

Положим, у нас с reminder_count происходят ещё какие-нибудь занимательные вещи, например мы его значение зачем-нибудь присваиваем другой переменной вот так:

<code lua>antirad_check_delay = reminder_count</code>

Ну и вот, если у нас reminder_count в момент присвоения ещё не имеет никакого значения, то мы получим занимательную штуку — у нас это выражение сработает как

<code lua>antirad_check_delay = nil</code>

В результате чего переменная antirad_check_delay «сдохнет» и будет деловито убрана «сборщиком мусора» из памяти, что моментально приведёт к вылету, когда в дальнейшем какая-то часть кода обратится к значению antirad_check_delay.

== Ошибки деления на 0 ==

Теперь положим что у нас reminder_count используется в каком-нибудь расчёте вот так:

<code lua>antirad_check_delay = exposure_count/reminder_count</code>

Как мы помним, у нас reminder_count не инициализирована, и как следствие равна nil. В итоге мы получим попытку поделить exposure_count на ноль (в нашем случае на nil, что суть одно и то же в нашем случае) и получим «классический» программистский вылет из-за ошибки деления на ноль.

== Ошибки присвоения ==

Предположим что мы написали скрипт, который помогает выбирать оружие при наличии вблизи врагов. И вот, у нас в скрипте есть такой кусок кода, где NPC вынимает из рюкзака оружие:

<code lua>function weapon_manager:set_weapon(wpn)

local enemy = self.npc:best_enemy()
if wpn then
--обратите внимание сюда
self.weapon_id = wpn:id()
--обратите внимание сюда
self:return_items(self.weapon_id)
else
printw(«set_wpn:weapon not exist»)
end
if self.modes.process_mode == "3" and enemy then
for k, v in pairs(self.weapons) do
for i, w in ipairs(v) do
if w.id ≈ self.weapon_id then
local item = level.object_by_id(w.id)
if item and item:parent() and item:parent():id() == self.npc_id then
printw(«set_weapon[%s]:process %s[%s]», self.npc:character_name(), w.id, w.sec)
self:process_item(item)
end
end
end
end
end
if enemy then
self.npc:set_item(object.idle, wpn)
end
self.weapons = nil

end</code>

В помеченном выражении self.weapon_id = wpn:id(), и всё вроде бы отлично, так как стоит проверка if wpn then, однако иногда движок умудряется передать объект функциям некорректно, либо сам скриптер может перепутать при вызове игровой объект с объектом а-лайфа, и присвовение self.weapon_id = wpn:id() либо приравняет self.weapon_id к nil либо сразу приведёт к вылету из-за того что соответствующее свойство объекта не было обнаружено в его классе.

== Как с этим бороться ==

Бороться с такими ситуациями очень просто на самом деле.
Во-первых: ВСЕГДА ИНИЦИАЛИЗИРУЙТЕ ПЕРЕМЕННЫЕ. То есть вот такое описание переменной:

<code>local reminder_count</code>

НЕДОПУСТИМО! ВЫ ОБЯЗАТЕЛЬНО ДОЛЖНЫ ЗАДАТЬ ПЕРЕМЕННОЙ ЗНАЧЕНИЕ!
Если переменная числовая, сделайте это так:

<code>local reminder_count = 0</code>

Если строчная — то сделайте это так:

<code>local reminder_count = ""</code> (получится вместо nil пустая строка)

Если логическая, то так:

<code>local reminder_count = false</code>

В общем, делайте так, как вам удобнее, но ДЕЛАЙТЕ ОБЯЗАТЕЛЬНО!

И во-вторых: ВСЕГДА ПРОВЕРЯЙТЕ ПЕРЕМЕННУЮ ПЕРЕД ИСПОЛЬЗОВАНИЕМ!

То есть в кусках кода, чреватых вылетами (к ним относятся АБСОЛЮТНО ВСЕ части, где идёт работа с вещами или оружием) обязательно вставляйте проверки переменных на nil следующим образом:

<code lua>if wpn and wpn:id() then
self.weapon_id = wpn:id()
end</code>

Тогда сначала выполнится проверка, и если обе переменные имеют значение, то операция отработает, а если один из параметров пуст — то функция просто пропустит этот код. Тут не помешает ещё и проверку вставить на существование self.weapon_id, хотя это наверное уже моя параноя :)

Кстати, что самое дурацкое — ошибки, приведённые выше, часто в лог попадают совершенно непохожим на ошибки скриптов образом. Например, ошибка присвоения из примера 3 приводила к вылету с сообщением «Assertion failed», и поймать её я смог только изучив внимательно предыдущие строки лога, где зафиксировались операции с вещами…

Точно так же, если вы используете ЛЮБЫЕ математические операции например деление (но не только деление, всего остального тоже касается), тоже ОБЯЗАТЕЛЬНО поверяйте переменную. Вот так:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
end</code>

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

<code lua>if wpn and wpn:id() then
self.weapon_id = wpn:id()
end</code>

Или таким:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
end</code>

И у вас в случае некорректного значения компилятор спокойно пропустил этот код, ничего не сделав ни с self.weapon_id (из первого примера), ни с antirad_check_delay (из второго). Однако вам всё-таки нужно, чтобы с ними что-то происходило, даже если проверяемые переменные неверны. Тогда я бы советовал вам дополнить этот обход отработкой нештатной ситуации. Делается это банально просто:

<code lua>if wpn and wpn:id()then
self.weapon_id = wpn:id()
elseif wpn == nil then
--вставьте сюда код, что делать если wpn не существует
elseif wpn:id() == nil then
--а сюда, если wpn:id() не существует
--тут скорее всего перепутан объект, и можно попробовать
--обратиться к wpn.id
end</code>

И для второго случая аналогично:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
else
--а тут что мы сделаем если reminder_count не существует
--я бы сделал например вот так:
antirad_check_delay = exposure_count/1
--и все дела
end</code>

Более конкретная реализация зависит от того, что именно вы пытаетесь сделать — тут уже вам виднее…

= Особенность вторая. Типичные ошибки при именовании функций, присвоении и инициализации переменных. =

Типичная ошибка, приводящая к вылету:

<code lua>function remove_item(remove_item)
if remove_item~=nil then
alife():release(alife():object(remove_item:id()), true)
return true
end
return false
end</code>

В этом коде агрумент функции совпадает с её именем, и в итоге функция пытается передать функции alife():release вместо указателя на вещь — указатель на саму себя. А так как у функции remove_item нет никакого id, код выпадает с ошибкой:

<code>Arguments : LUA error: ...\s.t.a.l.k.e.r\gamedata\scripts\test.script:486: attempt to call method 'id' (a nil value)</code>

Следует помнить, что Lua — это язык прямого (JIT) компилирования, и он, как любой такой язык не проверяет ошибки при компиляции. Поэтому нужно очень аккуратно раздавать имена переменным и функциям, чтобы избежать подобных ошибок. Данную функцию нужно переписать следующим образом:

<code lua>function remove_item(item_to_remove)
if item_to_remove then
alife():release(alife():object(item_to_remove:id()), true)
return true
end
return false
end</code>

Однажды, отлаживая скрипт, натолкнулся на вот такой код:

<code lua>function hit_callback(npc_id)
if db.storage[npc_id].wounded ≈ nil then
db.storage[npc_id].wounded.wound_manager:hit_callback()
end
end</code>

Казалось бы, всё верно, и значение проверяется перед использованием. Ан нет, скрипт вызывал вылет, причём именно на проверке. Методом тыка было выясено, что nil вызвавший вылет, был не в результате обработки, а был передан фукнции. Это был параметр npc_id.

Пришлось сделать вот так:

<code lua>function hit_callback(npc_id)
if npc_id and db.storage[npc_id].wounded ≈ nil then
db.storage[npc_id].wounded.wound_manager:hit_callback()
end
end</code>

Введя предварительно проверку аргумента npc_id. Вывод — если ставите проверку, старайтесь проверять не только саму функцию, но и вначале — аргумент, который ей передаётся. Мало ли в каком виде он до вас доедет… :)

Касательно именования переменных — не забывайте давать им атрибут local если вы не собираетесь их пользовать во внешних скриптах. Иначе, если попадётся где-то аналогичное имя — будет сбой логики или вылет, помните об этом.

И ещё один совет — для самых начинающих:

Когда пишете скрипты, не забывайте о соблюдении синтаксиса! То есть внимательно и вдумчиво ставьте в концах функций и оснований ключевые слова end — помните, что как отсутствие нужных end’ов, так и наличие лишних приводят к тому, что границы фукций сбиваются, скрипт не парсится обработчиком и вызывает при попытке своего вызова вылет, примерно вот такой:

<code>Arguments : LUA error: ...g\s.t.a.l.k.e.r\gamedata\scripts\bind_stalker.script:75: attempt to index global 'test_main_new' (a nil value)</code>

Для того, чтобы вам проще было следить за синтаксисом и не допускать лишних end’ов, выстраивайте текст скриптов каскадными лесенками:

<code >Начало_Работы
Начало_Внуренней_Функции
Процедуры_Внутреней_Функции
Конец_Внутренней_Функции
Конец_Работы</code>

..и пользуйтесь редакторами с подсветкой синтаксиса, такими как Notepad++ например. В результате каждый уровень вложенности находится на своём отступе. Вы всегда увидите, какую конструкцию нужно закрыть, а какую — нет. Я же например, делаю ещё проще — я, открывая новую функцию, сразу ставлю сразу в её конце, парой строк ниже, end, и потом уже пишу наполняющий её текст с отступами как в примере выше.

И ещё — касательно жизни переменных: не забывайте, что определённые внутри проверок переменные живут только до выхода из проверки. То есть, например:

<code lua>if check == 1 then
local test = true
else
local test = false
end</code>

В данном случае переменная test создастся, но просуществует только до выхода из проверки, и дальше обращение к ней выдаст nil. Для того чтобы этого избежать, определение переменных надо выносить «за скобки» вот так:

<code lua>local test = false; — инитим переменную и задаём сразу ей значение по умолчанию

if check == 1 then
test = true
else
test = false
end</code>

= Особенность третья. Смертельные циклы по таблицам. =

Если вы строите цикл по таблице следующим образом:

<code lua>for i=1, table.getn(table_name) do</code>

'''То никогда, ни при каких обстоятельствах не используйте внутри этого цикла удаление/добавление строк, т.е:'''

<code lua>table_name[i] = nil</code>

или

<code lua>table.remove(table_name, index)
table.insert(table_name, index)</code>

применительно к таблице по которой гоняете цикл!!! При использовании это приводит к тому, что количество строк в таблице уменьшается, а цикл пытается получить из таблицы строки сверх существующего количества, что в итоге приводит к выходу цикла за отведённый ему диапазон памяти. Результатом будет веер самых разнообразных последствий, самое безобидное из которых это безлоговый вылет на рабочий стол, а серьёзное — сбой в работе а-лайфа с последующим боем сейвов! Тяжесть последствий зависит от того, какие действия вы выполняете внутри цикла кроме удаления строки.

Чтобы избежать подобных ситуаций, стройте циклы по таблице лучше следующим образом:

<code lua>for k, v in pairs(table_name)</code>

А удаление строк внутри них делайте вот так:

<code lua>table_name[k] = nil</code>

Циклы же for i=1, table.getn(table_name) do следует использовать '''только для операций, не изменяющих структуру изменяемой таблицы!'''

= Особенность четвёртая. Как безопасно использовать коллбэки и таймерные события. =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

Как писать скрипты, не приводящие к вылетам и бою сейвов

2009-08-25T10:02:28Z

Kamikazze:

[[Категория:Статьи участников]]
= Предисловие =

'''Отладив несколько скриптов на предмет вылетов решил написать это небольшое руководство, чтобы помочь начинающим (да и опытным тоже) скриптописателям избежать потенциальных проблем.'''

Сразу оговорюсь — я программист, поэтому к отладке скриптов подхожу со своей профессиональной точки зрения, и то что я тут изложу вам — сие для программиста есть непреложная истина, и если вы хотите уменьшить количество глюков — старайтесь придерживаться нижеприведённого стиля программирования.

Для начала маленький экскурс в историю. Итак, скрипты в сталкере написаны на языке '''Lua''' — разработали его бразильцы, он очень гибок, легко встраивается в игры и поэтому очень часто используется для написания скриптов любой степени сложности. Так вот, у этого языка и его реализации в игре есть несколько исключительно важных особенностей, которые, при их несоблюдении, будут приводить к вылетам вашего скрипта. Итак:

= Особенность первая. Типы данных и проблемы с nil. =

Сначала сделаю маленькое отступление для не знакомых с основами скриптеров, чтобы понятнее было. Итак, в Lua используются следующие логические операторы:

<code>
= оператор присваивания
== сравнение, равно ли значение
≈ сравнение, НЕ равно ли значение
< сравнение, меньше ли значение
> сравнение, больше ли значение
<= сравнение, меньше ли значение или равно
>= сравнение, больше ли значение или равно
and логический оператор И
not логический оператор НЕ
or логический оператор ИЛИ</code>

Всё. Теперь поехали дальше… Язык Lua Изначально создавался для работы с большими строчными базами данных, поэтому ВСЕ виды конструкций в языке — это типы данных, то есть по сути либо переменные, либо константы. Это касается так же и функций! '''Поэтому даже с функциями в Lua можно и нужно обращатся как с переменными.''' Далее. Касательно, собственно «привычных» переменных. '''Обычные переменные в Lua получают свой тип данных только в момент присвоения им значения (запомните, это важно).''' При этом, в Lua есть такой важный и полезный тип данных как nil. nil — Это «пустота», то есть отсутствие какого-либо значения. При этом этот тип используется компилятором скриптов для «сбора мусора», то есть для освобождения занимаемой памяти. Смотрите пример, я объясню подробнее, что это значит:

<code lua>local reminder_count
local exposure_count = 0</code>

Тут у нас 2 локальные переменные, одна из которых просто создана, а вторая — создана и инициализарована. Если сейчас обратиться к переменной reminder_count, считав её значение, то мы получим в качестве значения — nil, то есть пустоту. Если же мы обратимся к переменной exposure_count — то получим, как и ожидали, 0 — так как мы это значение проинициализировали ЗАРАНЕЕ. '''При этом не надо путать nil и 0 — так как 0 — это всё-таки какая-то информация, а вот nil — это её полное отсутствие.''' Так вот, собственно, чем это чревато. Я уже сказал, что nil используется для сбора мусора. Вручную это работает так — когда вам переменная уже не нужна, вы просто пишете:

<code lua>test_variable = nil</code>

И ваша переменная test_variable сотрётся из памяти, и любые ссылки на неё будут выдавать на выходе nil (типа нет такой переменной, «абонент вне зоны действия сети»). Ну так собственно вот, зачем я это всё рассказываю… '''если не определить значение переменной сразу, как это было сделано с переменной reminder_count, то любые попытки обратиться к ней внутри скрипта приведут к вылетам.''' Происходит это следующим образом: допустим, reminder_count — это у нас счётчик напоминаний. То есть мы о чём-то напоминаем игроку текстовыми сообщениями, и помечаем, сколько раз мы это сделали. Определили мы переменную именно так, как в примере выше, то есть не задав ей никакого значения. Значение же её должно присваиваться ниже по коду, после первого оповещения юзера. При этом у нас есть в коде обращение к этой переменной, по которому решается что делать дальше. Выглядит это примерно так:

<code lua>function check_antirad_supplies()

if auto_injection_active then

if antirad_check_delay == nil or game.get_game_time():diffSec(antirad_check_delay) > 60 then

if not db.actor:object(«antirad») and not (use_scientific_kit and db.actor:object(«medkit_scientic»)) then

--обратите внимание сюда
if reminder_count == 0 or reminder_count >= mins_till_next_remind then
--обратите внимание сюда
if use_text then
local news_text = «%c[255,160,160,160]Автоматическая система ввода медицинских
препаратов\\n".."%c[default]Напоминаю: %c[255,230,0,0]
Противорадиационные препараты отстутствуют! %c[default]
Автоматический ввод препаратов невозможен.»
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal",
Frect():set(0,188,83,47), 0, 3000)
end
if use_sounds then
local snd_obj
if use_custom_sounds then
snd_obj = xr_sound.get_safe_sound_object([[HEV\no-anti-rad]])
else
snd_obj = xr_sound.get_safe_sound_object([[device\pda\pda_tip]])
end
if snd_obj then
snd_obj:play_no_feedback(db.actor, sound_object.s2d, 0, vector(), 1.0)
end
end
reminder_count = 1
elseif reminder then
reminder_count = reminder_count + 1
end

else
radiation_warning = true
reminder_count = 0
end
antirad_check_delay = game.get_game_time()
end
end
end</code>

Во время игры всё это скорее всего отработает хорошо, но вот при загрузке… тут могут быть проблемы, так как скрипт при запуске может пролететь ту часть, где переменной reminder_count присваивается значение! В итоге при запуске вышеприведённой функции check_antirad_supplies() нас получится что reminder_count не существует — он равен nil, и в итоге проверка

<code lua>if reminder_count == 0 or reminder_count >= mins_till_next_remind then</code>

выдаст ошибку и приведёт к вылету! Почему? '''Да потому что НЕЛЬЗЯ сравнивать НИЧТО с вещественным значением.''' Именно поэтому, когда вы создаёте новую переменную, вы ОБЯЗАНЫ задать ей значение по умолчанию, даже если вы полностью уверены, что она нигде не будет использована до инициализации. Поверьте — в программировании бывает всё, и запросто может так случиться, что ваша переменная будет использована и спровоцирует вылет.

Простой способ обойти такую кучу проверок и лишних инициализаций — использование or-оператора. пример

<code lua>if (reminder_count or 0) >= mins_till_next_remind then</code>

если переменная равна nil, то выражение вычисляется дальше и получается равным 0, а это уже число и сравнение происходит безболезненно.

Кроме вышеприведённой ситуации, возможен ещё один неприятный момент, связанный с определением переменных и значением nil. Суть его заключается в том, что при присваивании значений или операциями с переменными мы можем получить кучу проблем… покажу конкретнее каких:

== «Смерть» переменных ==

Положим, у нас с reminder_count происходят ещё какие-нибудь занимательные вещи, например мы его значение зачем-нибудь присваиваем другой переменной вот так:

<code lua>antirad_check_delay = reminder_count</code>

Ну и вот, если у нас reminder_count в момент присвоения ещё не имеет никакого значения, то мы получим занимательную штуку — у нас это выражение сработает как

<code lua>antirad_check_delay = nil</code>

В результате чего переменная antirad_check_delay «сдохнет» и будет деловито убрана «сборщиком мусора» из памяти, что моментально приведёт к вылету, когда в дальнейшем какая-то часть кода обратится к значению antirad_check_delay.

== Ошибки деления на 0 ==

Теперь положим что у нас reminder_count используется в каком-нибудь расчёте вот так:

<code lua>antirad_check_delay = exposure_count/reminder_count</code>

Как мы помним, у нас reminder_count не инициализирована, и как следствие равна nil. В итоге мы получим попытку поделить exposure_count на ноль (в нашем случае на nil, что суть одно и то же в нашем случае) и получим «классический» программистский вылет из-за ошибки деления на ноль.

== Ошибки присвоения ==

Предположим что мы написали скрипт, который помогает выбирать оружие при наличии вблизи врагов. И вот, у нас в скрипте есть такой кусок кода, где NPC вынимает из рюкзака оружие:

<code lua>function weapon_manager:set_weapon(wpn)

local enemy = self.npc:best_enemy()
if wpn then
--обратите внимание сюда
self.weapon_id = wpn:id()
--обратите внимание сюда
self:return_items(self.weapon_id)
else
printw(«set_wpn:weapon not exist»)
end
if self.modes.process_mode == "3" and enemy then
for k, v in pairs(self.weapons) do
for i, w in ipairs(v) do
if w.id ≈ self.weapon_id then
local item = level.object_by_id(w.id)
if item and item:parent() and item:parent():id() == self.npc_id then
printw(«set_weapon[%s]:process %s[%s]», self.npc:character_name(), w.id, w.sec)
self:process_item(item)
end
end
end
end
end
if enemy then
self.npc:set_item(object.idle, wpn)
end
self.weapons = nil

end</code>

В помеченном выражении self.weapon_id = wpn:id(), и всё вроде бы отлично, так как стоит проверка if wpn then, однако иногда движок умудряется передать объект функциям некорректно, либо сам скриптер может перепутать при вызове игоровой объект с объектов а-лайфа, и присвовение self.weapon_id = wpn:id() либо приравняет self.weapon_id к nil либо сразу приведёт к вылету из-за того что соответствующее свойство объекта не было обнаружено в его классе.

== Как с этим бороться ==

Бороться с такими ситуациями очень просто на самом деле.
Во-первых: ВСЕГДА ИНИЦИАЛИЗИРУЙТЕ ПЕРЕМЕННЫЕ. То есть вот такое описание переменной:

<code>local reminder_count</code>

НЕДОПУСТИМО! ВЫ ОБЯЗАТЕЛЬНО ДОЛЖНЫ ЗАДАТЬ ПЕРЕМЕННОЙ ЗНАЧЕНИЕ!
Если переменная числовая, сделайте это так:

<code>local reminder_count = 0</code>

Если строчная — то сделайте это так:

<code>local reminder_count = ""</code> (получится вместо nil пустая строка)

Если логическая, то так:

<code>local reminder_count = false</code>

В общем, делайте так, как вам удобнее, но ДЕЛАЙТЕ ОБЯЗАТЕЛЬНО!

И во-вторых: ВСЕГДА ПРОВЕРЯЙТЕ ПЕРЕМЕННУЮ ПЕРЕД ИСПОЛЬЗОВАНИЕМ!

То есть в кусках кода, чреватых вылетами (к ним относятся АБСОЛЮТНО ВСЕ части, где идёт работа с вещами или оружием) обязательно вставляйте проверки переменных на nil следующим образом:

<code lua>if wpn and wpn:id() then
self.weapon_id = wpn:id()
end</code>

Тогда сначала выполнится проверка, и если обе переменные имеют значение, то операция отработает, а если один из параметров пуст — то функция просто пропустит этот код. Тут не помешает ещё и проверку вставить на существование self.weapon_id, хотя это наверное уже моя параноя :)

Кстати, что самое дурацкое — ошибки, приведённые выше, часто в лог попадают совершенно непохожим на ошибки скриптов образом. Например, ошибка присвоения из примера 3 приводила к вылету с сообщением «Assertion failed», и поймать её я смог только изучив внимательно предыдущие строки лога, где зафиксировались операции с вещами…

Точно так же, если вы используете ЛЮБЫЕ математические операции например деление (но не только деление, всего остального тоже касается), тоже ОБЯЗАТЕЛЬНО поверяйте переменную. Вот так:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
end</code>

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

<code lua>if wpn and wpn:id() then
self.weapon_id = wpn:id()
end</code>

Или таким:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
end</code>

И у вас в случае некорректного значения компилятор спокойно пропустил этот код, ничего не сделав ни с self.weapon_id (из первого примера), ни с antirad_check_delay (из второго). Однако вам всё-таки нужно, чтобы с ними что-то происходило, даже если проверяемые переменные неверны. Тогда я бы советовал вам дополнить этот обход отработкой нештатной ситуации. Делается это банально просто:

<code lua>if wpn and wpn:id()then
self.weapon_id = wpn:id()
elseif wpn == nil then
--вставьте сюда код, что делать если wpn не существует
elseif wpn:id() == nil then
--а сюда, если wpn:id() не существует
--тут скорее всего перепутан объект, и можно попробовать
--обратиться к wpn.id
end</code>

И для второго случая аналогично:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
else
--а тут что мы сделаем если reminder_count не существует
--я бы сделал например вот так:
antirad_check_delay = exposure_count/1
--и все дела
end</code>

Более конкретная реализация зависит от того, что именно вы пытаетесь сделать — тут уже вам виднее…

= Особенность вторая. Типичные ошибки при именовании функций, присвоении и инициализации переменных. =

Типичная ошибка, приводящая к вылету:

<code lua>function remove_item(remove_item)
if remove_item~=nil then
alife():release(alife():object(remove_item:id()), true)
return true
end
return false
end</code>

В этом коде агрумент функции совпадает с её именем, и в итоге функция пытается передать функции alife():release вместо указателя на вещь — указатель на саму себя. А так как у функции remove_item нет никакого id, код выпадает с ошибкой:

<code>Arguments : LUA error: ...\s.t.a.l.k.e.r\gamedata\scripts\test.script:486: attempt to call method 'id' (a nil value)</code>

Следует помнить, что Lua — это язык прямого (JIT) компилирования, и он, как любой такой язык не проверяет ошибки при компиляции. Поэтому нужно очень аккуратно раздавать имена переменным и функциям, чтобы избежать подобных ошибок. Данную функцию нужно переписать следующим образом:

<code lua>function remove_item(item_to_remove)
if item_to_remove then
alife():release(alife():object(item_to_remove:id()), true)
return true
end
return false
end</code>

Однажды, отлаживая скрипт, натолкнулся на вот такой код:

<code lua>function hit_callback(npc_id)
if db.storage[npc_id].wounded ≈ nil then
db.storage[npc_id].wounded.wound_manager:hit_callback()
end
end</code>

Казалось бы, всё верно, и значение проверяется перед использованием. Ан нет, скрипт вызывал вылет, причём именно на проверке. Методом тыка было выясено, что nil вызвавший вылет, был не в результате обработки, а был передан фукнции. Это был параметр npc_id.

Пришлось сделать вот так:

<code lua>function hit_callback(npc_id)
if npc_id and db.storage[npc_id].wounded ≈ nil then
db.storage[npc_id].wounded.wound_manager:hit_callback()
end
end</code>

Введя предварительно проверку аргумента npc_id. Вывод — если ставите проверку, старайтесь проверять не только саму функцию, но и вначале — аргумент, который ей передаётся. Мало ли в каком виде он до вас доедет… :)

Касательно именования переменных — не забывайте давать им атрибут local если вы не собираетесь их пользовать во внешних скриптах. Иначе, если попадётся где-то аналогичное имя — будет сбой логики или вылет, помните об этом.

И ещё один совет — для самых начинающих:

Когда пишете скрипты, не забывайте о соблюдении синтаксиса! То есть внимательно и вдумчиво ставьте в концах функций и оснований ключевые слова end — помните, что как отсутствие нужных end’ов, так и наличие лишних приводят к тому, что границы фукций сбиваются, скрипт не парсится обработчиком и вызывает при попытке своего вызова вылет, примерно вот такой:

<code>Arguments : LUA error: ...g\s.t.a.l.k.e.r\gamedata\scripts\bind_stalker.script:75: attempt to index global 'test_main_new' (a nil value)</code>

Для того, чтобы вам проще было следить за синтаксисом и не допускать лишних end’ов, выстраивайте текст скриптов каскадными лесенками:

<code >Начало_Работы
Начало_Внуренней_Функции
Процедуры_Внутреней_Функции
Конец_Внутренней_Функции
Конец_Работы</code>

..и пользуйтесь редакторами с подсветкой синтаксиса, такими как Notepad++ например. В результате каждый уровень вложенности находится на своём отступе. Вы всегда увидите, какую конструкцию нужно закрыть, а какую — нет. Я же например, делаю ещё проще — я, открывая новую функцию, сразу ставлю сразу в её конце, парой строк ниже, end, и потом уже пишу наполняющий её текст с отступами как в примере выше.

И ещё — касательно жизни переменных: не забывайте, что определённые внутри проверок переменные живут только до выхода из проверки. То есть, например:

<code lua>if check == 1 then
local test = true
else
local test = false
end</code>

В данном случае переменная test создастся, но просуществует только до выхода из проверки, и дальше обращение к ней выдаст nil. Для того чтобы этого избежать, определение переменных надо выносить «за скобки» вот так:

<code lua>local test = false; — инитим переменную и задаём сразу ей значение по умолчанию

if check == 1 then
test = true
else
test = false
end</code>

= Особенность третья. Смертельные циклы по таблицам. =

Если вы строите цикл по таблице следующим образом:

<code lua>for i=1, table.getn(table_name) do</code>

'''То никогда, ни при каких обстоятельствах не используйте внутри этого цикла удаление/добавление строк, т.е:'''

<code lua>table_name[i] = nil</code>

или

<code lua>table.remove(table_name, index)
table.insert(table_name, index)</code>

применительно к таблице по которой гоняете цикл!!! При использовании это приводит к тому, что количество строк в таблице уменьшается, а цикл пытается получить из таблицы строки сверх существующего количества, что в итоге приводит к выходу цикла за отведённый ему диапазон памяти. Результатом будет веер самых разнообразных последствий, самое безобидное из которых это безлоговый вылет на рабочий стол, а серьёзное — сбой в работе а-лайфа с последующим боем сейвов! Тяжесть последствий зависит от того, какие действия вы выполняете внутри цикла кроме удаления строки.

Чтобы избежать подобных ситуаций, стройте циклы по таблице лучше следующим образом:

<code lua>for k, v in pairs(table_name)</code>

А удаление строк внутри них делайте вот так:

<code lua>table_name[k] = nil</code>

Циклы же for i=1, table.getn(table_name) do следует использовать '''только для операций, не изменяющих структуру изменяемой таблицы!'''

= Особенность четвёртая. Как безопасно использовать коллбэки и таймерные события. =

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

== Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback ==

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий

= Авторы =
Статья создана: [[Участник:Kamikazze|Kamikazze]]

Как писать скрипты, не приводящие к вылетам и бою сейвов

2009-08-25T08:45:57Z

Kamikazze: Создание новой статьи

'''Отладив несколько скриптов на предмет вылетов решил написать это небольшое руководство, чтобы помочь скриптописателям избежать потенциальных проблем.'''

Сразу оговорюсь — я программист, поэтому к отладке скриптов подхожу со своей профессиональной точки зрения, и то что я тут изложу вам — сие для программиста есть непреложная истина, и если вы хотите уменьшить количество глюков — старайтесь придерживаться нижеприведённого стиля программирования.

Для начала маленький экскурс в историю. Итак, скрипты в сталкере написаны на языке '''Lua''' — разработали его бразильцы, он очень гибок, легко встраивается в игры и поэтому очень часто используется для написания скриптов любой степени сложности. Так вот, у этого языка есть несколько исключительно важных особенностей, которые, при их несоблюдении, будут приводить к вылетам вашего скрипта. Итак:

== '''Особенность первая. Типы данных и проблемы с nil.''' ==

Сначала сделаю маленькое отступление, чтобы понятнее было. Итак, в Lua используются следующие операторы:

<code>= оператор присваивания
== сравнение, равно ли значение
≈ сравнение, НЕ равно ли значение
< сравнение, меньше ли значение
> сравнение, больше ли значение
<= сравнение, меньше ли значение или равно
>= сравнение, больше ли значение или равно
and логический оператор И
not логический оператор НЕ
or логический оператор ИЛИ</code>

Всё. Теперь поехали дальше… Язык Lua Изначально создавался для работы с большими строчными базами данных, поэтому ВСЕ виды конструкций в языке — это типы данных, то есть по сути либо переменные, либо константы. Это касается так же и функций! '''Поэтому даже с функциями в Lua можно и нужно обращатся как с переменными.''' Далее. Касательно, собственно «привычных» переменных. '''Обычные переменные в Lua получают свой тип данных только в момент присвоения им значения (запомните, это важно).''' При этом, в Lua есть такой важный и полезный тип данных как nil. nil — Это «пустота», то есть отсутствие какого-либо значения. При этом этот тип используется компилятором скриптов для «сбора мусора», то есть для освобождения занимаемой памяти. Смотрите пример, я объясню подробнее, что это значит:

<code lua>local reminder_count
local exposure_count = 0</code>

Тут у нас 2 локальные переменные, одна из которых просто создана, а вторая — создана и инициализарована. Если сейчас обратиться к переменной reminder_count, считав её значение, то мы получим в качестве значения — nil, то есть пустоту. Если же мы обратимся к переменной exposure_count — то получим, как и ожидали, 0 — так как мы это значение проинициализировали ЗАРАНЕЕ. '''При этом не надо путать nil и 0 — так как 0 — это всё-таки какая-то информация, а вот nil — это её полное отсутствие.''' Так вот, собственно, чем это чревато. Я уже сказал, что nil используется для сбора мусора. Вручную это работает так — когда вам переменная уже не нужна, вы просто пишете:

<code lua>test_variable = nil</code>

И ваша переменная test_variable сотрётся из памяти, и любые ссылки на неё будут выдавать на выходе nil (типа нет такой переменной, «абонент вне зоны действия сети»). Ну так собственно вот, зачем я это всё рассказываю… '''если не определить значение переменной сразу, как это было сделано с переменной reminder_count, то любые попытки обратиться к ней внутри скрипта приведут к вылетам.''' Происходит это следующим образом: допустим, reminder_count — это у нас счётчик напоминаний. То есть мы о чём-то напоминаем игроку текстовыми сообщениями, и помечаем, сколько раз мы это сделали. Определили мы переменную именно так, как в примере выше, то есть не задав ей никакого значения. Значение же её должно присваиваться ниже по коду, после первого оповещения юзера. При этом у нас есть в коде обращение к этой переменной, по которому решается что делать дальше. Выглядит это примерно так:

<code lua>function check_antirad_supplies()

if auto_injection_active then

if antirad_check_delay == nil or game.get_game_time():diffSec(antirad_check_delay) > 60 then

if not db.actor:object(«antirad») and not (use_scientific_kit and db.actor:object(«medkit_scientic»)) then

--обратите внимание сюда
if reminder_count == 0 or reminder_count >= mins_till_next_remind then
--обратите внимание сюда
if use_text then
local news_text = «%c[255,160,160,160]Автоматическая система ввода медицинских
препаратов\\n".."%c[default]Напоминаю: %c[255,230,0,0]
Противорадиационные препараты отстутствуют! %c[default]
Автоматический ввод препаратов невозможен.»
db.actor:give_game_news(news_text, "ui\\ui_iconsTotal",
Frect():set(0,188,83,47), 0, 3000)
end
if use_sounds then
local snd_obj
if use_custom_sounds then
snd_obj = xr_sound.get_safe_sound_object([[HEV\no-anti-rad]])
else
snd_obj = xr_sound.get_safe_sound_object([[device\pda\pda_tip]])
end
if snd_obj then
snd_obj:play_no_feedback(db.actor, sound_object.s2d, 0, vector(), 1.0)
end
end
reminder_count = 1
elseif reminder then
reminder_count = reminder_count + 1
end

else
radiation_warning = true
reminder_count = 0
end
antirad_check_delay = game.get_game_time()
end
end
end</code>

Во время игры всё это скорее всего отработает хорошо, но вот при загрузке… тут могут быть проблемы, так как скрипт при запуске может пролететь ту часть, где переменной reminder_count присваивается значение! В итоге при запуске вышеприведённой функции check_antirad_supplies() нас получится что reminder_count не существует — он равен nil, и в итоге проверка

<code lua>if reminder_count == 0 or reminder_count >= mins_till_next_remind then</code>

выдаст ошибку и приведёт к вылету! Почему? '''Да потому что НЕЛЬЗЯ сравнивать НИЧТО с вещественным значением.''' Именно поэтому, когда вы создаёте новую переменную, вы ОБЯЗАНЫ задать ей значение по умолчанию, даже если вы полностью уверены, что она нигде не будет использована до инициализации. Поверьте — в программировании бывает всё, и запросто может так случиться, что ваша переменная будет использована и спровоцирует вылет.

Простой способ обойти такую кучу проверок и лишних инициализаций — использование or-оператора. пример

<code lua>if (reminder_count or 0) >= mins_till_next_remind then</code>

если переменная равна nil, то выражение вычисляется дальше и получается равным 0, а это уже число и сравнение происходит безболезненно.

Кроме вышеприведённой ситуации, возможен ещё один неприятный момент, связанный с определением переменных и значением nil. Суть его заключается в том, что при присваивании значений или операциями с переменными мы можем получить кучу проблем… покажу конкретнее каких:

'''1) «Убийство» переменных'''

Положим, у нас с reminder_count происходят ещё какие-нибудь занимательные вещи, например мы его значение зачем-нибудь присваиваем другой переменной вот так:

<code lua>antirad_check_delay = reminder_count</code>

Ну и вот, если у нас reminder_count в момент присвоения ещё не имеет никакого значения, то мы получим занимательную штуку — у нас это выражение сработает как

<code lua>antirad_check_delay = nil</code>

В результате чего переменная antirad_check_delay «сдохнет» и будет деловито убрана «сборщиком мусора» из памяти, что моментально приведёт к вылету, когда в дальнейшем какая-то часть кода обратится к значению antirad_check_delay.

'''2) Ошибки деления на 0.'''

Теперь положим что у нас reminder_count используется в каком-нибудь расчёте вот так:

<code lua>antirad_check_delay = exposure_count/reminder_count</code>

Как мы помним, у нас reminder_count не инициализирована, и как следствие равна nil. В итоге мы получим попытку поделить exposure_count на ноль (в нашем случае на nil, что суть одно и то же в нашем случае) и получим «классический» программистский вылет из-за ошибки деления на ноль.

[b]3) Ошибки присвоения.[/b]

Предположим что мы написали скрипт, который помогает выбирать оружие при наличии вблизи врагов. И вот, у нас в скрипте есть такой кусок кода, где NPC вынимает из рюкзака оружие:

<code lua>function weapon_manager:set_weapon(wpn)

local enemy = self.npc:best_enemy()
if wpn then
--обратите внимание сюда
self.weapon_id = wpn:id()
--обратите внимание сюда
self:return_items(self.weapon_id)
else
printw(«set_wpn:weapon not exist»)
end
if self.modes.process_mode == "3" and enemy then
for k, v in pairs(self.weapons) do
for i, w in ipairs(v) do
if w.id ≈ self.weapon_id then
local item = level.object_by_id(w.id)
if item and item:parent() and item:parent():id() == self.npc_id then
printw(«set_weapon[%s]:process %s[%s]», self.npc:character_name(), w.id, w.sec)
self:process_item(item)
end
end
end
end
end
if enemy then
self.npc:set_item(object.idle, wpn)
end
self.weapons = nil

end</code>

В помеченном выражении self.weapon_id = wpn:id(), и всё вроде бы отлично, так как стоит проверка if wpn then, однако иногда движок умудряется передать объект функциям некорректно, либо сам скриптер может перепутать при вызове игоровой объект с объектов а-лайфа, и присвовение self.weapon_id = wpn:id() либо приравняет self.weapon_id к nil либо сразу приведёт к вылету из-за того что соответствующее свойство объекта не было обнаружено в его классе.

'''Как с этим бороться.'''

Бороться с такими ситуациями очень просто на самом деле.
Во-первых: ВСЕГДА ИНИЦИАЛИЗИРУЙТЕ ПЕРЕМЕННЫЕ. То есть вот такое описание переменной:

<code>local reminder_count</code>

НЕДОПУСТИМО! ВЫ ОБЯЗАТЕЛЬНО ДОЛЖНЫ ЗАДАТЬ ПЕРЕМЕННОЙ ЗНАЧЕНИЕ!
Если переменная числовая, сделайте это так:

<code>local reminder_count = 0</code>

Если строчная — то сделайте это так:

<code>local reminder_count = ""</code> (получится вместо nil пустая строка)

Если логическая, то так:

<code>local reminder_count = false</code>

В общем, делайте так, как вам удобнее, но ДЕЛАЙТЕ ОБЯЗАТЕЛЬНО!

И во-вторых: ВСЕГДА ПРОВЕРЯЙТЕ ПЕРЕМЕННУЮ ПЕРЕД ИСПОЛЬЗОВАНИЕМ!

То есть в кусках кода, чреватых вылетами (к ним относятся АБСОЛЮТНО ВСЕ части, где идёт работа с вещами или оружием) обязательно вставляйте проверки переменных на nil следующим образом:

<code lua>if wpn and wpn:id() then
self.weapon_id = wpn:id()
end</code>

Тогда сначала выполнится проверка, и если обе переменные имеют значение, то операция отработает, а если один из параметров пуст — то функция просто пропустит этот код. Тут не помешает ещё и проверку вставить на существование self.weapon_id, хотя это наверное уже моя параноя :)

Кстати, что самое дурацкое — ошибки, приведённые выше, часто в лог попадают совершенно непохожим на ошибки скриптов образом. Например, ошибка присвоения из примера 3 приводила к вылету с сообщением «Assertion failed», и поймать её я смог только изучив внимательно предыдущие строки лога, где зафиксировались операции с вещами…

Точно так же, если вы используете ЛЮБЫЕ математические операции например деление (но не только деление, всего остального тоже касается), тоже ОБЯЗАТЕЛЬНО поверяйте переменную. Вот так:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
end</code>

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

<code lua>if wpn and wpn:id() then
self.weapon_id = wpn:id()
end</code>

Или таким:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
end</code>

И у вас в случае некорректного значения компилятор спокойно пропустил этот код, ничего не сделав ни с self.weapon_id (из первого примера), ни с antirad_check_delay (из второго). Однако вам всё-таки нужно, чтобы с ними что-то происходило, даже если проверяемые переменные неверны. Тогда я бы советовал вам дополнить этот обход отработкой нештатной ситуации. Делается это банально просто:

<code lua>if wpn and wpn:id()then
self.weapon_id = wpn:id()
elseif wpn == nil then
--вставьте сюда код, что делать если wpn не существует
elseif wpn:id() == nil then
--а сюда, если wpn:id() не существует
--тут скорее всего перепутан объект, и можно попробовать
--обратиться к wpn.id
end</code>

И для второго случая аналогично:

<code lua>if reminder_count and reminder_count ≈ 0 then
antirad_check_delay = exposure_count/reminder_count
else
--а тут что мы сделаем если reminder_count не существует
--я бы сделал например вот так:
antirad_check_delay = exposure_count/1
--и все дела
end</code>

Более конкретная реализация зависит от того, что именно вы пытаетесь сделать — тут уже вам виднее…

== '''Особенность вторая. Типичные ошибки при именовании функций, присвоении и инициализации переменных.''' ==

Типичная ошибка, приводящая к вылету:

<code lua>function remove_item(remove_item)
if remove_item~=nil then
alife():release(alife():object(remove_item:id()), true)
return true
end
return false
end</code>

В этом коде агрумент функции совпадает с её именем, и в итоге функция пытается передать функции alife():release вместо указателя на вещь — указатель на саму себя. А так как у функции remove_item нет никакого id, код выпадает с ошибкой:

<code>Arguments : LUA error: ...\s.t.a.l.k.e.r\gamedata\scripts\test.script:486: attempt to call method 'id' (a nil value)</code>

Следует помнить, что Lua — это язык прямого (JIT) компилирования, и он, как любой такой язык не проверяет ошибки при компиляции. Поэтому нужно очень аккуратно раздавать имена переменным и функциям, чтобы избежать подобных ошибок. Данную функцию нужно переписать следующим образом:

<code lua>function remove_item(item_to_remove)
if item_to_remove then
alife():release(alife():object(item_to_remove:id()), true)
return true
end
return false
end</code>

Однажды, отлаживая скрипт, натолкнулся на вот такой код:

<code lua>function hit_callback(npc_id)
if db.storage[npc_id].wounded ≈ nil then
db.storage[npc_id].wounded.wound_manager:hit_callback()
end
end</code>

Казалось бы, всё верно, и значение проверяется перед использованием. Ан нет, скрипт вызывал вылет, причём именно на проверке. Методом тыка было выясено, что nil вызвавший вылет, был не в результате обработки, а был передан фукнции. Это был параметр npc_id.

Пришлось сделать вот так:

<code lua>function hit_callback(npc_id)
if npc_id and db.storage[npc_id].wounded ≈ nil then
db.storage[npc_id].wounded.wound_manager:hit_callback()
end
end</code>

Введя предварительно проверку аргумента npc_id. Вывод — если ставите проверку, старайтесь проверять не только саму функцию, но и вначале — аргумент, который ей передаётся. Мало ли в каком виде он до вас доедет… :)

Касательно именования переменных — не забывайте давать им атрибут local если вы не собираетесь их пользовать во внешних скриптах. Иначе, если попадётся где-то аналогичное имя — будет сбой логики или вылет, помните об этом.

И ещё один совет — для самых начинающих:

Когда пишете скрипты, не забывайте о соблюдении синтаксиса! То есть внимательно и вдумчиво ставьте в концах функций и оснований ключевые слова end — помните, что как отсутствие нужных end’ов, так и наличие лишних приводят к тому, что границы фукций сбиваются, скрипт не парсится обработчиком и вызывает при попытке своего вызова вылет, примерно вот такой:

<code>Arguments : LUA error: ...g\s.t.a.l.k.e.r\gamedata\scripts\bind_stalker.script:75: attempt to index global 'test_main_new' (a nil value)</code>

Для того, чтобы вам проще было следить за синтаксисом и не допускать лишних end’ов, выстраивайте текст скриптов каскадными лесенками:

<code >Начало_Работы
Начало_Внуренней_Функции
Процедуры_Внутреней_Функции
Конец_Внутренней_Функции
Конец_Работы</code>

..и пользуйтесь редакторами с подсветкой синтаксиса, такими как Notepad++ например. В результате каждый уровень вложенности находится на своём отступе. Вы всегда увидите, какую конструкцию нужно закрыть, а какую — нет. Я же например, делаю ещё проще — я, открывая новую функцию, сразу ставлю сразу в её конце, парой строк ниже, end, и потом уже пишу наполняющий её текст с отступами как в примере выше.

И ещё — касательно жизни переменных: не забывайте, что определённые внутри проверок переменные живут только до выхода из проверки. То есть, например:

<code lua>if check == 1 then
local test = true
else
local test = false
end</code>

В данном случае переменная test создастся, но просуществует только до выхода из проверки, и дальше обращение к ней выдаст nil. Для того чтобы этого избежать, определение переменных надо выносить «за скобки» вот так:

<code lua>local test = false; — инитим переменную и задаём сразу ей значение по умолчанию

if check == 1 then
test = true
else
test = false
end</code>

== '''Особенность третья. Смертельные циклы по таблицам.''' ==

Если вы строите цикл по таблице следующим образом:

<code lua>for i=1, table.getn(table_name) do</code>

'''То никогда, ни при каких обстоятельствах не используйте внутри этого цикла удаление/добавление строк, т.е:'''

<code lua>table_name[i] = nil</code>

или

<code lua>table.remove(table_name, index)
table.insert(table_name, index)</code>

применительно к таблице по которой гоняете цикл!!! При использовании это приводит к тому, что количество строк в таблице уменьшается, а цикл пытается получить из таблицы строки сверх существующего количества, что в итоге приводит к выходу цикла за отведённый ему диапазон памяти. Результатом будет веер самых разнообразных последствий, самое безобидное из которых это безлоговый вылет на рабочий стол, а серьёзное — сбой в работе а-лайфа с последующим боем сейвов! Тяжесть последствий зависит от того, какие действия вы выполняете внутри цикла кроме удаления строки.

Чтобы избежать подобных ситуаций, стройте циклы по таблице лучше следующим образом:

<code lua>for k, v in pairs(table_name)</code>

А удаление строк внутри них делайте вот так:

<code lua>table_name[k] = nil</code>

Циклы же for i=1, table.getn(table_name) do следует использовать '''только для операций, не изменяющих структуру изменяемой таблицы!'''

== '''Особенность четвёртая. Как безопасно использовать коллбэки и таймерные события.''' ==

В скриптовом движке есть удобный способ реакции на события - использование коллбэков - процедурных вызовов, привязанных к определённым событиям в жизни игрового объекта - получению повреждений, спавну, смерти и т.д. и т.п. Это hit_callback, death_callback из xr_motivator и многие другие... Все моддеры очень широко и совершенно спокойно пользуются ими, совершенно забывая при этом о таком важном факте, что это - обработки реального времени, как и таймерные события. Что это значит? А собственно вот что... Возьмём для примера коллбэк смерти неписей, мою головную боль последнего времени:

<code>xr_motivator.script -
function motivator_binder:death_callback(victim, who)</code>

Это функция обрабатывает смерть неписей. Когда вызывается этот коллбек он начинает по очереди вызывать внутренние функции, расположенные в других модулях. Они разрегистрируют умершего непися в гулагах, спавнят в него лут, обновляют статистику, отключают его от доп. схем логики и т.д.

Так вот, обычно, когда в функциях возникает конфликт параметров, бесконечный цикл, попытка индексации nil и т.д., функция вылетает со стандартным логом. '''Но только не в случае, когда она находится внутри коллбэка. Если функция внутри него, то в случае возникновении в ней любой нештатной ситуации, коллбэк наглухо виснет.''' Это происходит из-за того, что функции вызываются строго друг за другом, и каждая из них вызывается только тогда, когда её предшественница вернула управление коллбэку. В случае с death_callback опознать такого непися очень просто - в его трупе окажется фонарик, КПК и возможно ещё немного разных "мусорных" вещей, что говорит о том, что обработка его смерти повисла не дойдя даже до спавна лута. В подобной ситуации можно быть на 100% уверенным, что труп этот не был корректно разрегистрирован, и игра всё ещё считает его живым неписем. Кроме того, зависший коллбэк не освобождает стек (а он у Луа-подсистемы единый на все скрипты), что '''в итоге приводит к вылетам игры с переполнением памяти (вот она, реальная причина этих "родных" вылетов).''' Но было бы слишком хорошо, если бы всё ограничивалось этим... однако тут всё намного хуже... такие "зависшие" коллбэки, особенно если их произошло несколько подряд, очень серьёзно влияют на работу а-лайфа. В лучшем случае они, забивая, стек, мешают нормально работать схемам логики, в худшем вызывают зависания самого а-лайфа (этот эффект, кстати, производят и сами трупы таких неписей, так как они, как мы помним, не разрегистрировались корректно). '''Основной итог таких событий - бой сейвов, сделанных после возникновения таких ситуаций.''' Если повис один коллбэк, то такие сейвы ещё через раз загружаются, если же несколько, и остановилась работа а-лайфа - всё, сейвы бьются наглухо и реанимации не подлежат.

Поэтому, чтобы избежать такого развития событий, каждый раз, когда вы вносите в коллбэк новую функцию - проверьте её самым тщательным образом. Она не должна содержать никаких рекурсивных циклов, в ней обязательно должны быть проверки на валидность обрабатываемых объектов и значений, и обязательно должна быть обработка нештатных ситуаций - т.е. функция должна обязательно, в абсолютно любой ситуации вернуть управление коллбэку, так или иначе. В самом наихудшем случае - делайте как делали разработчики игры - вставляйте принудительный вылет на рабстол функцией abort - она позволяет передавать отладочное сообщение, и это всяко лучше чем незаметный бой сейвов. Если обработка оборвалась в самом начале, а ф-ция обязательно должна вернуть значение - заведите ей "безопасное" возвращаемое значение по-умолчанию, которое она будет выдавать, если всё пошло плохо. И никогда не пренебрегайте пошаговой отладкой коллбэков с выводом в лог, особенно когда пишете схемы логики - это критически важно для стабильности вашего мода.

'''Основные внутриигровые признаки зависания коллбэков типа hit_callback, death_callback:'''

1. В трупах попадаются фонарики, КПК, разный мусор и общий лут слишком богат.

2. Частые вылеты во время интенсивных боёв с логами типа
Sheduler tried to update object...
smart_terrain:1145(1146)
LUA: out of memory
любой_модуль_логики:любая_cтрока - stack overflow

3. Частые "родные" вылеты в момент смерти непися или попадания по нему

4. Произвольно бьются сейвы во время сражений, выброса и других насыщенных действиями событий