HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Half-Life SDK (https://hlfx.ru/forum/forumdisplay.php?forumid=8)
-- Кажется, я починил DispatchAnimEvents (https://hlfx.ru/forum/showthread.php?threadid=5590)

Ну который FreeSlave здесь написал или это просто пример.

Next Day это вполне рабочий код. Первый блок можно в monsters.cpp, не забыв сделать декларацию этой функции в классе CBaseMonster. Второй в schedule.cpp, в какой-нибудь таск из TASK_FIND_COVER_FROM_ENEMY, TASK_FIND_COVER_FROM_ORIGIN, TASK_FIND_COVER_FROM_BEST_SOUND в функции CBaseMonster :: StartTask.

Спасибо теперь мне более понятно.

Уау, круто!

__________________

Killing Floor: Horzine Outbreak

__________________
Мой мод на Xash

Немного поясню, если вдруг непонятно, что за интервал проверки эвентов такой, от flStart до flEnd.
Есть pev->frame. Это не конкретный кадр в анимации, которых может быть от 1 до лимита, поддерживаемого движком и форматом моделей. Это диапазон от первого кадра до последнего, для удобства приведённый к определённому максимальному значению. В сорсе это 0 - 1, в голдсорсе 0 - 255. Соответственно, когда диапазон меньше минимума или больше максимума - m_fSequenceFinished = TRUE.
DispatchAnimEvents вызывает GetAnimationEvent внутри этого диапазона, эвент ищется с позиции flStart по позицию flEnd. В сорсовском варианте рассинхронов нет, т.к. значения позиций берутся непосредственно из анимации. А вот в голдсорсовском происходит шняга, потому что значения зачем-то доумножаются на gpGlobals->time и зависящую от неё pev->animtime.
Изначально, похоже, вальвовцы не хотели втыкать m_fSequenceFinished в StudioFrameAdvance, о чём говорит коммент, оставленный в этой функции. Но так как даже двойная проверка не помогла, пришлось использовать flInterval (совпадающий с частотой тчинка понстров), чтобы эвенты не проскакивали. Это также не спасло ситуацию, т.к. GetAnimationEvent в этом случае всё равно может срабатывать не вовремя.

Ku2zoff тебе уже пора заводить свой блог разработчика

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Барник стал тупить у меня. Именно из-за этих изменений с анимациями.
Ситуация: стоит барник в режиме idle, я с ноуклипом и ноутаргетом спавню гранта впереди и справа от барника. Грант спавнится спиной к барнику и не видит его. Барник поворачивается к монстру, и...его зацикливает и не отпускает. Просто стоит и дрожит.
Я нажимаю на барника, его отпускает и он начинает стрелять.

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

__________________
Мой мод на Xash

Тут вот какая странность. У меня у барника заменная модель.
Я поставил родную модель и бага нет. С моей моделью и твоим кодом баг проявился 2 раза из трех. С родной - ни разу из 4-ех раз (условия идеальные - стоящий барник, рядом монстермейкер, который я активирую - больше на карте никого (плоская площадка с колоннами, ноды есть).
Может что-то не так с самой анимацией draw?

Добавлено 03-12-2020 в 08:51:

Я свою модель чуть редактировал, поэтому нашел оригинал и проверил. С ней тоже этот баг есть. Прикрепляю.

Добавлено 03-12-2020 в 08:53:

И вот как у меня сделана карта. Монстермейкер и барник.
Находясь в ноутаргете, активирую монстремейкер через консоль.
https://drive.google.com/file/d/1ru...iew?usp=sharing

__________________
Мой мод на Xash

Я сейчас воспроизведу условия. А ты удалил flInterval = 0.1 из DispatchAnimEvents? Оно тоже не нужно после внесения изменений.

Ага, скорее всего не удалил с работы вернусь, проверю

__________________
Мой мод на Xash

Aynekko ну что сказать. У меня с твоей моделью баг периодически проявляется. Пользуясь методом Дяди Миши (читай, используя пролетарское чутьё), я сразу понял, что что-то с перехватом эвентов у конкретной анимации, потому что модель весьма самопальная, аж из Азур Шипа. Что выяснилось: в модели две анимации с активностью ACT_ARM - draw и draw_as. Так вот, с некоторой вероятностью иногда играется вторая, т.к. она дальше по списку. Я сразу же закомментил первую, чтобы всегда игралась вторая, и баг стал воспроизводиться в 100% случаев.
Оказалось, что эвент 2 (BARNEY_AE_DRAW), отвечающий за смену переменной m_fGunDrawn у барника, в этой анимации поставлен на последний, 15-й кадр. И он просто не выхватывается новым кодом. Переставил на 14-й, и всё заработало. Значит, надо либо убрать вторую анимацию, либо изменить кадр эвента, либо ковырять код и выяснять, почему такое происходит.
Надо бы проверить все стандартные халфовские модели, которые использованы в игре. Если хотя бы у одной есть анимация с вызовом эвента на последнем кадре, тогда надо править код. Если нет - просто в своих моделях не ставить ничего на последний кадр.

Добавлено 03-12-2020 в 18:16:

Итак, что выяснилось. Эвенты, поставленные на первый (0) кадр, проскакивают как в оригинале, так и с новым кодом, но не всегда. Например, хедкрабы вполне кусают игрока. А вот выстрелы у грантов срабатывают не всегда. Эвенты на последнем кадре (если кадров в анимации 10, то его номер 9, т.к. отсчёт идёт с 0) в оригинале срабатывают, в новом коде - нет. Меня терзают смутные сомнения, что и в оригинале эвенты на последнем кадре могут проскакивать. Скорее всего, это всё зависит от попадания GetAnimationEvent в момент тчинка монстра. Единственная здравая мысль, которая приходит в голову, это не располагать эвенты на первом и последнем кадрах. А это влечёт за собой переделку некоторых моделей, где есть эвенты на нулевом кадре, чтобы потенциально избежать несрабатываний.

Добавлено 03-12-2020 в 18:35:

Собсно, в коде GetAnimationEvent условие игнорирует последний кадр в случае нелупленных анимаций:

if ( (pevent[index].frame >= flStart && pevent[index].frame < flEnd) ||

  ((pseqdesc->flags & STUDIO_LOOPING) && flEnd >= pseqdesc->numframes - 1 && pevent[index].frame < flEnd - pseqdesc->numframes + 1) )

1

bool bOverlapEvent = false;

2

3

if (pevent[index].cycle >= flStart && pevent[index].cycle < flEnd)

4

{

5

  bOverlapEvent = true;

6

}

7

// FIXME: doesn't work with animations being played in reverse

8

else if ((pseqdesc->flags & STUDIO_LOOPING) && flEnd < flStart)

9

{

10

  if (pevent[index].cycle >= flStart || pevent[index].cycle < flEnd)

11

  {

12

    bOverlapEvent = true;

13

  }

14

}

Блин, классные вещи вы делаете. Тут можно серию туторов сделать как для голды, так и для ксаша. Для мододелов было бы круто иметь продвинутых нпс. Я для себя вот про адекватных зомбачелло мечтаю)
Надеюсь, и их прокачаете

__________________

Killing Floor: Horzine Outbreak