Ham_Killed или DeathMsg

В общем есть две всем известные функции Ham_Killed и DeathMsg. Если сразу после убийства игрока попробовать вывести данные о хедшотах (полученных в DeathMsg) через Ham_Killed то кол-во хедов всегда почему то опаздывает на 1 хедшот, а почему хз.. DeathMsg считает правильно.


Это значение будет всегда верным, при нужных условиях конечно.


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

Частично найшел обход с костылем: set_task. Видимо функция не сразу обновляет данные.

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

Перефразировал пост. +Я о том что 'Ham_Killed' с познячком =)

Почему бы просто не ловить хедшот в Ham_Killed ?


Или можно оффсетом m_iLastHitGroup узнать куда в последний раз нашему клиенту прилетело.



В HL он 90, в Op4 93, а вот в CS фз.

Код:

get_user_attacker

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


Потому что мне надо знать умер ли он от подачи в каску, а не ловить их.

Тогда почему не отлавливать смерть вместо Ham_Killed в DeathMsg ?

понял.. Я думал об этом как о запасном варианте. Хотелось все таки разобратся с Ham_Killed =)

Да это действительно удобно. Учитывая что изначально у меня:
Код:

register_event("DeathMsg", "some_fc", "a", "1>0")

Я уже объяснил в сообщении #5.
if(hitPlace == HIT_HEAD) - условие "прилетело в каску".


Ок.
Почему бы не перенести код из Ham_Killed в DeathMsg ?

В общем вариантов уйма... спасибо.


Ham_Killed с тормозом.. врят ли это прокатит.


проще уже сразу все сделать через DeathMsg =)

Это DeathMsg с тормозом.
Ham_Killed вызывается сразу как только что-то здохло. А твой DeathMsg вызывает уже после этого события.