HLFX.Ru Forum - Кажется, я починил DispatchAnimEvents

Страницы (10): « 1 2 3 4 [5] 6 7 8 9 » ... Последняя »
Показать все 138 сообщений этой темы на одной странице

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)

Отправлено Ku2zoff 05-12-2020 в 18:02:

ncuxonaT как плечи качаются, так и качаются остальные руки. Лень мне ковыряться. Типа дышит, пусть будет как есть.

Добавлено 06-12-2020 в 01:02:

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

Отправлено FreeSlave 06-12-2020 в 09:45:

Цитата:

Ku2zoff писал:
Будем посмотреть. Возможно, придётся действительно заводить список врагов.

Я ещё подумал на эту тему. В HL же есть разные градации неприязни. Если барник в качестве врага получит кого-то кого он "ненавидит" (HATE), то будет игнорить всех, к кому степень неприязни ниже (DISLIKE), соответственно и твои проверки на TOOCLOSE скорее всего не сработают (ну смотря как ты написал). Т.е. может возникнуть ситуация, когда ненавидимый враг стоит далеко, а другой подходит вплотную к барнику, и тот убегать не станет.

В общем, ещё один аргумент в пользу смены системы.

__________________
I'm on github
I'm on opendesktop.org

Отправлено Ku2zoff 06-12-2020 в 18:34:

Закончил барника с дробовиком. Нужно немного отполировать анимацию стрельбы и сделать анимации поворотов направо и налево.

Отправлено Ku2zoff 07-12-2020 в 01:01:

Цитата:

FreeSlave писал:
Если ты убрал из шедули прерывание по bits_COND_NEW_ENEMY, то барник и не будет получать врагов до тех пор, пока эта шедуля играется.

У меня есть подозрение, что сегодня я нарвался на такой баг. Барник застрелил одного зомби и побежал перезаряжаться. Упёрся лбом во второго и продолжил бежать в него как в стенку. Ну и выхватил. Попытаюсь воспроизвести и отловить. Если повторится, придётся решать проблему.

Отправлено Aynekko 09-12-2020 в 08:47:

Раз уж тут вроде и про AI разговор, то вопрос такой. Все перекопал, но не могу найти, где это поменять.
Ситуация: солдат уже заметил игрока и бежит за ним. Забегаем за угол, потом сразу же выходим. Солдат останавливается и смотрит на игрока где-то секунду, и только потом стреляет. Этого достаточно, чтобы заходить за угол туда-сюда и расстрелять солдата, ни разу не получив урона. Как бы сделать, чтобы он сразу стрелял?

Добавлено 09-12-2020 в 11:47:

Ну как это часто бывает, я пишу сюда, а потом понимаю, что делать. Животворящий форум. В общем, попробовал сделать так и кажется, это сработало:
В CBaseMonster :: CheckEnemy я поменял условие

C++ Source Code:

1	if ( !FVisible( pEnemy ) )

3	ASSERT(!HasConditions(bits_COND_SEE_ENEMY));

4	SetConditions( bits_COND_ENEMY_OCCLUDED );

Это как было. Здесь я закомментировал строчку SetConditions.
Далее, идут условия:

C++ Source Code:

1	if ( HasConditions( bits_COND_SEE_ENEMY ) )

  .......

3	else if ( !HasConditions(bits_COND_ENEMY_OCCLUDED\|bits_COND_SEE_ENEMY) && ( flDistToEnemy <= 256 ) )

  .......

else

И вот в этом else я прописал вот такое:

C++ Source Code:

if (m_flLastTimeObservedEnemy + 3 <= gpGlobals->time)

  SetConditions( bits_COND_ENEMY_OCCLUDED );

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

__________________
Мой мод на Xash

Отправлено FreeSlave 09-12-2020 в 10:40:

Aynekko, и откуда ты взял m_flLastTimeObservedEnemy? Это же не стандартная переменная.

По поводу поведения солдата: надо смотреть, что ему прерывает шедулю следования и какая выставляется. По тому, что я вижу, bits_COND_ENEMY_OCCLUDED прерывает атаку, но не движение. Смену шедулей можно отследить. Valve даже оставила отключенный код с алертами в ChangeSchedule.

__________________
I'm on github
I'm on opendesktop.org

Отправлено Aynekko 09-12-2020 в 11:20:

Цитата:

FreeSlave писал:
m_flLastTimeObservedEnemy

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

Цитата:

FreeSlave писал:
bits_COND_ENEMY_OCCLUDED прерывает атаку, но не движение

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

__________________
Мой мод на Xash

Отправлено FreeSlave 09-12-2020 в 11:44:

Цитата:

Aynekko писал:
У тебя с гитхаба, ага, большое спасибо.

Ну раз используешь мою кодовую базу, то жду багрепортов, а то и пуллреквестов

Цитата:

Aynekko писал:
он просто теряет игрока, потом я тут же выхожу из-за угла и он начинает снова - остановка, проверка атаки, потом стрельба

Т.е. ты всё-таки говоришь об остановке во время атаки, а не во время движения. Да, есть такая проблема. Я даже волтигорам убрал bits_COND_ENEMY_OCCLUDED из шедули атаки, потому что анимация создания заряда довольно долгая, да и сам заряд летит не мгновенно, так что такая проверка ни к чему. Раз уж начала - пусть стреляет. О том, чтобы применить нечто подобное к другим монстрам, я не думал. Хотя стоило бы.

__________________
I'm on github
I'm on opendesktop.org

Отправлено Aynekko 09-12-2020 в 12:01:

Цитата:

FreeSlave писал:
жду багрепортов

Да тут вроде все понятно, через 15 секунд они восстанавливаются на позицию

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

Цитата:

FreeSlave писал:
убрал bits_COND_ENEMY_OCCLUDED из шедули атаки, потому что анимация создания заряда довольно долгая, да и сам заряд летит не мгновенно, так что такая проверка ни к чему. Раз уж начала - пусть стреляет.

Не думаю, что стоит совсем уж убирать. Попробуй как у меня сделать может? И то, в эти три секунды они могут в стену стрелять, т.к. враг якобы все еще здесь…но это лучше, чем тупняк на месте. В большинстве случаев это выглядит как подавляющий огонь, что тоже здорово. Я у себя еще сделал рандом у солдат при occluded, 60% шанса кинуть грену и 30% range attack1. С этой новой проверкой этот рандом можно и убрать будет.

__________________
Мой мод на Xash

Отправлено FreeSlave 10-12-2020 в 12:28:

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

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

В общем, нужно ввести какую-то меру против частого переключения между противниками. Можно было бы вообще убрать прерывание по bits_COND_NEW_ENEMY для шедулей атак, но это может привести к ситуации, когда монстр с дистанционной атакой перестанет обращать внимание на противников, которые подошли ближе к нему и продолжать стрелять по врагу на расстоянии.

Цитата:

Aynekko писал:
Да тут вроде все понятно, через 15 секунд они восстанавливаются на позицию

Я сделал, чтоб они к последней известной позиции врага пытались пройти. Не забудь кстати эту переменную в save/restore добавить, а то я отдельным коммитом это поправил.
Ещё по идее надо подправить взаимодействие с PushEnemy и PopEnemy. В списке старых противников может оказаться тот же противник, что был и в m_hEnemy до того, как монстр о нём "забыл", и PopEnemy снова вытащит его же в качестве противника. Т.е. надо либо не допускать одновременного нахождения одного и того же монстра и в m_hEnemy и в m_hOldEnemy, либо вычищать его из списка при забывании.

__________________
I'm on github
I'm on opendesktop.org

Отправлено Ku2zoff 10-12-2020 в 14:07:

Цитата:

FreeSlave писал:
В общем, нужно ввести какую-то меру против частого переключения между противниками.

Надо пробовать завести массив врагов. Одного m_hEnemy явно недостаточно. m_hEnemies[MAX_ENEMIES]. И каким-то образом назначать им приоритет, как например weight у оружия. И считать этот приоритет, исходя из близости врага, его отношения к монстру, монстерстейта, в котором находится враг, какую атаку в данный момент враг выполняет... Короче много всего. Например, может быть отношение R_HATE или R_NEMESIS между хьюман грантами и алиен грантами. Хьюман грант в данный момент разбирается с зомби, который рядом с ним, и видит алиен гранта вдалеке. Из-за отношения переключается на него, не добивает зомби, у которого осталось 5 хп. Этот зомби валит хьюман гранта. А вот если считать приоритеты, тут уже можно сделать вариации: если у зомби мало хп, хьюман грант его добивает, и переключается на алиен гранта. Если у зомби хп много, то учитытвая, что алиен грант не враг зомби, хьюман грант сваливает за угол.

Отправлено Дядя Миша 10-12-2020 в 14:19:

Цитата:

Ku2zoff писал:
Надо пробовать завести массив врагов. Одного m_hEnemy явно недостаточно. m_hEnemies[MAX_ENEMIES]

C++ Source Code:

1	#define MAX_OLD_ENEMIES 4 // how many old enemies to remember

3	EHANDLE m_hOldEnemy[ MAX_OLD_ENEMIES ];

4	Vector m_vecOldEnemy[ MAX_OLD_ENEMIES ];

И в коде монстра соответственно PushEnemy и PopEnemy. Скажи пожалуйста, почему я, который в коде монстров вообще не ковырялся, об этом в курсе, а ты, который уже много лет улучшает AI до сих пор об этом не знаешь. Мне прямо страшно что ты там мог натворить.

__________________
My Projects: download page

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

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 10-12-2020 в 14:27:

Дядя Миша я об этом знаю, и ничего там не натворил. Но поведение монстров требует исправления. Push и Pop - не выход, т.к. монстр всегда оперирует только m_hEnemy. При bits_COND_NEW_ENEMY он благополучно пушает старого врага в память и творит неадекватщину, например перестаёт убегать в укрытие и получает по щщам от нового врага или от обоих сразу.

Отправлено Дядя Миша 10-12-2020 в 14:36:

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

__________________
My Projects: download page

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

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 10-12-2020 в 14:42:

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

Временная зона GMT. Текущее время 10:48.

Страницы (10): « 1 2 3 4 [5] 6 7 8 9 » ... Последняя »
Показать все 138 сообщений этой темы на одной странице

На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024