Народная 2010 разработка

[WhatAbout 8]

Доброго дня всем!

 

Да простит меня Уважаемый куратор, что пишу не в тему Вылетов, но хотелось бы поделиться с мастерами наблюдениями по вылету/завису ... attempt to index local 'respawner'

 

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

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

 

1. В файле se_respawn.script в функции function se_respawn:create(prob) перед вызовом amk.on_REspawn(obj,self) добавил вывод

sak.dbglog("SPAWN [%s] -> [%s]", tostring(self:name()), obj:name())

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

 

У меня таким "нехорошим человеком" оказался некий товарищ свободовец из Варлаба, имеющий

self:name

warlab_svobodovzu_respawn_1

и obj:name

warlab_svobodovzu_respawn_256852

 

2. Когда виновник был идентифицирован, в ту же функцию function se_respawn:create(prob), только немного выше - перед строкой

if spawn_section == "" then

добавил проверку

if tostring(self:name()) == "warlab_svobodovzu_respawn_1" then

return false

end

(наверное, было бы более правильно по obj:name, но так радикальнее...)

 

3. Загрузил сейв перед зависом - нет человека - нет проблемы.

Наверное, если бы такой нехорошего свойства респавн был не один, - пришлось бы

после первого ловить следующий завис. У меня он был один.

Игра дальше идет нормально (может, до следующего "нетакого"? ).

 

Понимаю, что подобные потуги не решают проблему в корне. И могут быть даже чем-то чреваты.

Но, вероятно, можно попытаться доиграть до победного

После прохождения момента некорректного респавна правочки в скрипте закоментировал.

Про запас.

 

Хороший вариант для выявления проблемных неписей. Но о таких нужно тут же сообщать Архаре - возможно проблема в их конфиге, логике или ещё каких настройках. sapsan

 

Архара,

 

warlab_svobodovzu_respawn_1 - это не человек, это респавн гулага. Тем самым был убит респавн свободы на Варлабе.

 

Эх, не люблю убивать, даже респавн... Но надоевший завис по 'respawner' убивает напрочь весь мир Солянки. Приходится выбирать, чтобы хотя бы таким боком продвинуться дальше.

Надеюсь, с Витамином договоримся

Изменено 4 Июня 2010 пользователем WhatAbout

[WhatAbout 8]

Shadowman,

 

Ну, и я перенес.

 

Повторюсь.

Сам удивлен

Но пока подтверждается на нескольких версиях Соли, даже прошлогодней...

Не очень силен в луа, поэтому объяснить достоверно не могу.

Вариант простой задержки - может быть, не очень проверял.

Но вывод в консоль той же функцией просто левого текста на дает такого эффекта.

Что там "внутре" при вызове метода execute - чесно, не разбирался. Но что-то же дает такой эффект.

Может, иннициализация какая внутренняя, или проверка корректности чего-то с подрихтовочкой.

Был бы признателен, если бы кто разобрался до конца.

А пока - по правилу "работает-не трогай".

 

P.S. Добавлю. Характерно, что использование вместо прямого вызова

get_console():execute("load ~ Spawn now ["..tostring(self:name()).."] -> ["..obj:name().."]")

функции abort

abort("Spawn now ["..tostring(self:name()).."] -> ["..obj:name().."]")

не спасает - вылет в smart_terrain.script по attempt to index a function value.

Хотя что там у нас в abort? Ну, почти то же, если не считать локальную переменную.

Как тут быть с "предположением про простую задержку"?

 

Кстати, параметры в функцию по адресу передаются или по значению?

 

dimos,

Я это и имел ввиду туманно написав "или проверка корректности чего-то с подрихтовочкой"

 

dimos,

Как проверить сработал ли респавн до конца? Существование объекта проверять? Не имел, к сожалению, достаточно времени, чтобы углубиться.

se_respawn.script: вызов amk.on_REspawn(obj,self) - amk.script: вызов mod_call("respawned",obj,respawner) - amk_mod.script local sini = respawner:spawn_ini() - строка, на которой и получался завис - отрабатывает.

Больше пока не проверял.

Изменено 7 Июня 2010 пользователем WhatAbout

[WhatAbout 8]

Shadowman,

 

Возможно ли такое, что в момент подготовки параметров для вызова get_console():execute каким либо образом валидируются некие данные, относящиеся к объекту-респавнеру. Ну, навроде добавления отсутствующего символа конца строки или иннициализации неопределенного явно свойства, etc.

Простите мой французский...

 

Shadowman,

WhatAbout, не думаю. Возможен только вылет в случае, если в строку попытаемся запихать переменную, которая нил

Тогда мне не совсем понятно такое:

1)

get_console():execute("load ~ Spawn now ["..self:name().."]") -- Ok

2)

local some = tostring(self:name())

get_console():execute("load ~ Spawn now ["..some.."]") -- висим

 

К слову,

3)

get_console():execute("load ~ Spawn now ["..level:name().."]") -- висим

зато!

4)

get_console():execute("", self:name()) -- Ok

 

dimos,

Насколько я смог проверить респавн происходит. Статистики, правда, не набрал. Проверял и по id и по name.

Изменено 8 Июня 2010 пользователем WhatAbout

[WhatAbout 8]

V92,

Позволю себе вставить пять копеек.

Уже насколько камрадов попадают на вылет Not enough IDs после установки последнего патча (от 27.06).

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

Количество объектов в этих сейвах до вылета не очень большое ~30 тыс.

Т.е. в какой-то момент имеет место старт создания огромного количества объектов.

 

sapsan,

Есть подозрение на нечто se_respawn.script, он ведь правился в последнем патче. Один из пострадавших от Not enough IDs "неспециально" вернул сей скрипт из пред.патча, пока играет.

 

Изменено 5 Июля 2010 пользователем WhatAbout

[WhatAbout 8]

Dennis_Chikin,

C емкостью гулагов и количеством работ не все на месте

Это те, что точно не бьют.

Смарты generators_flesh1, generators_tushkano, generators_snork работы в load_job (gulag_escape.script)

Смарт atp_flesh1 работы в load_job (gulag_new.script, здесь еще, по-моему может вылезти atp_dog1)

При формировании таблиц для этих смартов table.insert(sj, t) делается не для всех работ.

А в gulag:load_jobs() рассчитывается общая capacity -> capacity_non_exclusive.

Добавление недостающих insert-ов количества выравнивает, отрицательный capacity_non_exclusive не вылазит.

 

С живностью проще, а вот:

sak_lager - емкость в all.spawn прописана 3, но 4 ексклюзива

bar_visitors - 10 емкость, 12 ексклюзивов

warlab_svobodovzu - 19 емкость, 20 ексклюзивов ???

 

От сего получается:

1. gulag:load_jobs() [xr_gulag.script]

-- загрузка работ, подсчет gulag.capacity

...

self.capacity_non_exclusive = self.capacity

...

 

2. se_smart_terrain:preserve_exclusives() [smart_terrain.script]

local e = exclusives[self:name()]

if e then

...

self.exclusives = e

...

self.gulag.capacity_non_exclusive = self.gulag.capacity_non_exclusive - e < 0 !

 

И еще 3. Вызов gulag:load_jobs() из se_smart_terrain:remove_gulag после уничтожения гулага и создания нового

self.gulag:load_jobs()

self.gulag_working = false

self.gulag.capacity_non_exclusive = self.gulag.capacity_non_exclusive - self.exclusives < 0 !

 

 

Упомянутого ужаса не ощутил. Пока все уходящие по ходу игры - как у тебя под спойлером, т.е. вроде норм. Продолжим.

 

Dennis_Chikin,

Еще надо разбираться с гулагами, у которых ID есть, а самих - нет.

Это какие и где ловятся?

Хвост лога? Так это, имхо, нормально. Просто гулаги в этот момент уже не существуют. Проверял на выбор часть strn_id, у которых при закрытии/переходе no smart terrain, во время игры - эти гулаги существуют и работают. Может не все проверил - так при закрытии записей no smart terrain тьма...

 

atp_fabrika_bandit - 24 емкость : 24 работы (по крайней мере со старта)? Может здесь в другом трабл...

Изменено 19 Декабря 2010 пользователем WhatAbout