AI additions

[kamikazze 266]

Bak

 

Не надо мне рассказывать, пожалуйста про "основы". Я рыл скрипт очень плотно и отписался не просто так. Я ставил в коде ловушки с выводом значений в лог, используя get_console():execute, отлаживая этот вылет построчно, и оказалось что с периодичностью (редко, но тем не менее) self.weapon_id оказывается nil непосредственно перед выполнением этого присвоения. В основном это происходит когда игрок приближается к неписю на радиус действия a-life. После этого попытка выполнения вышеуказанного кода сразу вызывает вылет с assertion failed. Вставил поверку на существование self.weapon_id - вылеты пропали. Код же, который выполняется после этой строки имеет проверки на это значение, и там никаких проблем нет...

 

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

 

Тем более что у вас в коде выше, в периодически вызываемой функции обновлении менеждера вооружений - function weapon_manager:update() - проверки на существование self.weapon_id натыканы сплошь и рядом...

 

Перепроверил сейчас - да, именно это присвоение. ХЗ что тут не так, по-идее даже если self.weapon_id не существует, в этом случае эта переменная должна проинициализироваться, под неё должна выделиться память и должно быть присвоено значение. Но вместо этого происходит вылет, хотя wpn вроде существует. Сейчас поставлю вывод в лог и попробую проверить, возможно каким-то образом wpn:id() возвращает nil...

 

Есть кнопка "изменить" - прошу ей пользоваться. Предупреждение. N6260

 

Так, выяснил что сам себя несколько ввёл себя и вас в заблуждение, пардон. Этот вылет получается происходит из-за того, что при существующей переменной wpn периодически wpn:id() возвращает nil. Переменная же self.weapon_id тут получается ни при чём. Поправил в итоге вот так:

 

function weapon_manager:set_weapon(wpn)
if wpn and wpn:id() then
	--вставил проверку на величину, чтобы избежать вылета из-за попытки присвоить id несуществующей переменной
self.weapon_id = wpn:id()
	self:return_items(self.weapon_id)
--		printf("set_weapon[%s]:set %s[%s]",self.npc:character_name(),wpn:id(),wpn:section())
else
	printw("set_wpn:weapon not exist")
end

 

Уже пару дней интенсивно тестим, вылеты больше не повторялись. Но теперь нашёл другой очень редкий вылет - происходит сразу после того, когда отстреляли собак с Лисом. Лис говорит фразу в стиле "Ну славно, вроде отстрелялись", и игра вылетает без лога. Что интересно, вылет репродуцируем только на 6-м патче, на 5-м он не происходит. Сейчас трассирую построчно на какой строке кода происходит вылет, поймаю - отпишу где.

Изменено 18 Апреля 2009 пользователем kamikazze

[kamikazze 266]

Monnoroch

 

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

[kamikazze 266]

Ackeu

 

В новой версии неписям добавлена функция определения нет ли на линии огня друга. В этом случае они должны не стрелять. Еще кроме этого скрипт перезарядки теперь считывает количество патронов в магазине прямо из конфига оружия. Ну и ещё несколько небольших правок.

 

Bak

 

А ведь правда, нельзя ли историю изменений в шапку вынести?

[kamikazze 266]

Ackeu

 

Да незачто...

Насчёт адаптированной для амк141+2патча+аи пак от хСтрима - не ко мне, я только для OGSE мода делал адаптацию, но кстати там всё очень удобно вместе сводится, друг другу не мешает.

[kamikazze 266]

Сделал поправки некоторых проблем менеджера, с разрешения автора выкладываю тут:

 

http://deathdoor.ru/mod_ogse/ai_add_SHOC_f...4-11_patch_5.7z

http://ifolder.ru/23063515

 

Поправлены вылеты вида:

[error]Expression    : assertion failed
[error]Function      : xrServer::Process_event_reject
[error]File          : E:\stalker\sources\trunk\xr_3da\xrGame\xrServer_process_event_reject.cpp
[error]Line          : 12
[error]Description   : e_parent && e_entity

 

А так же напрямую связанная с ними проблема с пропажей части оружия NPC при выходе в онлайн. Эти вылеты иногда происходят когда NPC уходит в оффлайн - в этот момент менеджер вооружений для них отключается и возвращает вещи. Так вот, зачастую похоже что game_object непися успевает исчезнуть из игры раньше чем ему вернутся все вещи, в итоге происходят такие вылеты. Ситуация дурацкая - оставить так нельзя - вылетает периодически. Если же заворачивать обработку если непись не онлайн - тогда в итоге он теряет часть вещей, что неприемлемо. Пришлось отлавливать ситуацию когда непись вот-вот выпадет оффлайн и в этот момент шмот возвращать. Пришлось проверять условие пригодности для вывода в оффлайн и в случае если можно - проверять дистанцию переключения. Если дистанция в радиусе переключения - то поехали.

 

В связи с этим изменены три скрипта:

 

rx_wmgr.script - добавлена функция для отлова момента передачи вещей и флаг-блокировщик

xr_motivator.script - убран вызов функции rx_ai.npc_switch_offline(self.object) в методе net_destroy

se_stalker.script - модифицирован код проверки на пригодность к выводу в оффлайн и вставлен вызов новой функции из rx_wmgr

 

 

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

 

[kamikazze 266]

Артос

 

добавят сложностей для неопытных с адаптациями к другим модам (тот же массив перевода объектов он/офф-лайн из АМК, задействованный и в se_stalker).

 

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

 

local switch_dist = system_ini():r_s32("alife","switch_distance")
local switch_fact = system_ini():r_float("alife","switch_factor")
local real_off_dist = switch_dist*(1+switch_fact)

 

т.е. если расстояние от него до актора более или равно real_off_dist, и уже получено разрешение на выход в оффлайн, т.е. se_stalker:can_switch_offline() вернуло true (в этой ситуации непись уже фактически начал переход, после второго срабатывания can_switch_offline он вывалится в офф). При этом сделан небольшой таймаут. Поэтому пущщай себе в онлайн/оффлайн гуляют на здоровье, в любом случае при выходе в оффлайн шмот они получат назад. Если будут балансировать на границе, то для них пока будут балансировать просто будет выключено укладывание оружия в ящик, т.е. всё их оружие просто будет при них.

 

основанный на предсказании перехода

 

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

 

1. Уже есть в родной схеме

2. Тоже

3. У нас в ОГСЕ они вообще из аллспавна заспавнены и имеют стори_ид, т.е. ящик известен всегда. Но для портируемой схемы не прокатит.

4. Лишний геморрой по моему. Проще и думается надёжнее будет если просто они не будут бросать оружие при уходе в офф, чего я и добивался.

 

а) уже

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

в) трансфер между ящиками возможен только если оба в онлайне. Переброс самого ящика вариант реализуемый, но не слишком ли громоздко?

 

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

 

 

Добавлено через 4 мин.:

один флаг (temp_disable), время жизни которого до 0.5 сек на несколько неписей

 

Да пущщай уходят, пока работает флаг, неписи просто не могут выложить оружие в ящик - т.е. тут нет основы для нестабильности. Если ушло несколько сразу, этот период может затянуться на секунды две, три максимум (потому что в офф они как правило выходят сразу почти), но не вижу тут вроде бы ничего криминального Поэтому и флаг один на всех сделал

Изменено 19 Апреля 2011 пользователем kamikazze

[kamikazze 266]

Artos

 

2.

а) ага, пожалуй

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

 

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

 

Вот это кстати не пойму зачем... В родном паке это есть, вроде даже сразу было - там просто сделано у Бака - при сейве актора все вещи из ящика раздаются владельцам, и только затем игра сохраняется. Проверял, работает как надо, вещи при - сейв/лоадах и переходах между локациями не теряются. Пропадания были только когда ГГ убегал от непися на расстояние алайфа. Кстати, там же прямо в функции трансфера есть принудительное выпихивание ящика в онлайн, т.е. проверка на это вообще не требуется.

 

При правильной организации это совершенно не проблема и 'грязи' не остается.

 

Ну да, только стоит ли городить огород...

 

Хм, спавнить ящики в all.spawn'е, да на каждую локацию, да их на каждой искать/инициализировать, ...

 

Вот как раз чтобы не искать и не инициализировать это и сделано Ящиков всего по одному на локацию, добаляются элементарно, у каждого есть свой story_id, и в заголовке скрипта табличка вида локация=стори_ид_ящика. В родной схеме ящик ищется перебором всех ид, у нас же сейчас просто вот так:

 

        local lname = level.name()
        local id = id_by_sid(wmgr_boxes[lname])
        local obj = sim:object(id)
        if obj and obj:section_name() == "wmgr_box" then
            -- printf("manage_box:%s",id)
            box = obj
            boxid = id
        end

 

И все дела. Работает не в пример быстрее, так как перебор просто не нужен. Плюс всегда когда надо можно к ящику обратиться сразу, опять же используя story_id

 

Сам ящик может быть и стораджем массива парентов и еще чего ..., не загружая ни актора ни самих неписей и будучи при акторе (считай доп.сторадж).

 

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

[kamikazze 266]

Сделав типа: tm_pause = time_global() + math.max( 50, (real_off_dist - dist)*100 ) - можно на ближних дистанциях неписей отсекать проверки секундными паузами. По удалению - таймер перестраивается на сотни/десятки милисекунд.

 

Дельно, надо будет сделать.

 

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

 

Ну при этой ситуации оружие в любом случае погибнет вместе с владельцем, тут без вариантов, увы

 

Иметь доступное хранилище 'на всякий случай' все проще, чем изворачиваться потом.

 

Внутри большого мода да, у нас есть сейчас шикарное хранилище на 6,5 Кб - хоть упихайся, плюс работающее чисто на движковом функционале, и не пользующее ни кастомдату, ни пстор актора. Делается совсем несложно, но вот чистый мини-мод таким функционалом мне нагружать ой как не хочется, потому что портируемость схемы упадет - мало ли что там наверчено куда это прикручивать будут. Я вообще не любитель сохранять куда-то какие-то данные (и это говорит человек, запихавший в объект машины кодированную структуру багажника, бггг), стараюсь по возможности делать всё почти аппаратно-жестко, чтобы не зависело от целостности структуры где данные хранятся.