Кажется, я починил DispatchAnimEvents. Досконально не тестировал, но скрипт на карте gruntbattledemo в спирите стал работать значительно лучше. Да и вроде монстры стали меньше тупить. Проблема поднималась на форуме как минимум один раз тут. Как Дядя Миша писал выше, проблема в обнулении m_fSequenceFinished, и последующем проигрывании секвенции n-ное количество раз, пока, наконец, m_fSequenceFinished не станет true.
Я сравнил код из халфы с кодом из hl2beta, а затем из se2007. SourceSDK 2013 не смотрел, т.к. уверен, что принципиальных отличий нет. Хрен его знает зачем, но в первой халфе вальва сделала в вычислении диапазона эвента привязку к gpGlobals->time. А это, как оказалось, имеет зависимость от фпс и даёт нехорошие погрешности. Вот этот код в animating.cpp, void CBaseAnimating :: DispatchAnimEvents ( float flInterval )
C++ Source Code:
1
// FIXME: I have to do this or some events get missed, and this is probably causing the problem below
По комментам понятно, что эта фигня глючит, да ещё и m_fSequenceFinished приходится выставлять в TRUE ещё один раз, если StudioFrameAdvance этого не делает. Если приглядеться, то flStart и flEnd это не время, а кадры в диапазоне от 0 до 256. И вот тут-то доходит, в чём отличие сорсовской версии. Там нет привязки к времени. То есть никаких pev->animtime и gpGlobals->time, только диапазон от 0 до 1
C++ Source Code:
1
float flStart = m_flLastEventCheck;
2
float flEnd = m_flCycle;
3
4
if (!m_bSequenceLoops && m_bSequenceFinished)
5
{
6
flEnd = 1.0f;
7
}
8
m_flLastEventCheck = flEnd;
Я взял, да и зменил исходный код на сорсовский с изменениями:
C++ Source Code:
1
float flStart = m_flLastEventCheck;
2
float flEnd = pev->frame;
3
4
if (!m_fSequenceLoops && m_fSequenceFinished)
5
flEnd = 256.0f;
6
7
m_flLastEventCheck = flEnd;
Ну и ещё в ResetSequenceInfo поменял m_flLastEventCheck = gpGlobals->time; на m_flLastEventCheck = 0; В коде цыклера это надо тоже сделать.
Короче, вроде бы работает лучше, будем посмотреть.
Добавлено 01-12-2020 в 04:10:
Вдогонку видос с доработанным барником. Разобрался, как грамотно чекать врагов, чтобы монстр убегал от них резвее. Когда добавлю ему это - ближнебойные потенциально не смогут его завалить.
Отправлено Aynekko 01-12-2020 в 08:14:
Ku2zoff, это просто отлично хотелось бы видеть тутор по фиксу AI - это очень бы пригодилось всем.
Aynekko по сути это не фикс, а дописывание функционала барника с использованием того, что есть в дефолтном AI. Но кое-что я всё-таки поменял. Обкатаю и протестирую, и может быть напишу тутор. Ещё кое-что сделано не совсем правильно, но результат уже хороший: выживаемость у него выросла. Даже боюсь представить, что будет с грантами и ассассинами - они живучее и подвижнее.
Отправлено FreeSlave 01-12-2020 в 09:06:
Ku2zoff, попозже попробую твои фиксы анимаций тоже. В идеале такие изменения нужно отдельными коммитами выкладывать на какой-нибудь гитхаб. Чтобы заинтересованные могли глянуть, что поменялось в сравнении с оригиналом, и видеть только необходимое множество изменений.
FreeSlave писал: попозже попробую твои фиксы анимаций тоже
Дело не только в анимациях, но ещё и в щедъюлях. В некоторых из них есть TASK_WAIT и TASK_STOP_MOVING там, где они вообще не нужны. Например, SCHED_TAKE_COVER_FROM_ENEMY. Монстр теряет целую секунду на этих двух строчках. Если их закомментить, барник отваливает от врагов почти сразу, как они подойдут. Если отредактировать все щедъюли, то ненужных пауз между действиями не будет.
Отправлено Aynekko 01-12-2020 в 10:18:
Цитата:
Ku2zoff писал: Я взял, да и зменил исходный код на сорсовский с изменениями:
Цитата:
Ku2zoff писал: Ну и ещё в ResetSequenceInfo поменял m_flLastEventCheck = gpGlobals->time; на m_flLastEventCheck = 0;
Сделал это и гранты с дробовиками стали очень быстро стрелять. Автоматчики вроде нормальные остались.
Aynekko а у меня норм стреляют. Сравнивай, чем отличаются гранты и CBaseAnimating в ксашмоде и в халфе.
Отправлено FreeSlave 01-12-2020 в 13:13:
Цитата:
Ku2zoff писал: Дело не только в анимациях, но ещё и в щедъюлях.
Я про DispatchAnimEvents. Так как проблема двойного срабатывания ивентов действительно существует.
По поводу шедулей я кстати тебе в личку писал свои мысли. Мб ты пропустил сообщение?
Цитата:
Если их закомментить, барник отваливает от врагов почти сразу, как они подойдут. Если отредактировать все щедъюли, то ненужных пауз между действиями не будет.
Мне кажется, ожидания в некоторых местах всё же нужны. Иначе возможна ситуация, когда монстр будет постоянно пытаться построить путь, что может быть трудоёмко для старых компов, особенно если монстров много.
Кстати ошибка построения пути наверно самая частая причина непредусмотренных прерываний (т.е. срабатывающих не по условию в свойствах шедули).
FreeSlave писал: Мне кажется, ожидания в некоторых местах всё же нужны.
Конечно нужны. Иначе выглядит нелепо: на одном из моих видео барник сначала бежит к одной ноде лицом, а потом бежит почти боком к другой. Тут надо сам код FindCover переписывать. В голдсорсе ищется нода, если она подходит по критериям, монстр движется к ней, если достиг её - return TRUE - TaskComplete(). А правильнее надо так: ищется нода, если подходит по критериям, то BuildRoute до ноды, если успешно, монстр движется. Если вдруг не дошёл, пробуем другой маршрут до ноды, или ищем новую ноду. Снова BuildRoute и движение. И вот когда дошёл - TaskComplete(). А то обычным способом (если немного подкрутить функцию на поиск соседних связанных нод) он начинает метаться между нодами не меняя angles, что выглядит по-уродски. А если не подкрутить на поиск, то вообще TaskFailed() и искорки над головой.
Уважаемые админы, вырежьте нам пожалуйста из этой темы посты начиная с этого в отдельную тему. Эта ведь для вопросов, а не обсуждений и демонстрации.
Отправлено FreeSlave 01-12-2020 в 16:04:
Ku2zoff, не совсем тебя понял. FindCover зовёт MoveToLocation, который суть просто непрямой вызов того же BuildRoute. Т.е. ты описал два одинаковых случая (если не брать в расчёт предложенное перестраивание пути). А непосредственно движение выполняется вообще не в шедулях.
Бег боком это тоже что-то новенькое - наверно в твоих библиотеках. В HL то монстры (кроме контроллеров) всегда поворачиваются по направлению движения.
FreeSlave писал: MoveToLocation, который суть просто непрямой вызов того же BuildRoute
Точно, тупанул. Казалось, BuildRoute вызывается до начала движения, а не из одной функции с ним.
Цитата:
FreeSlave писал: В HL то монстры (кроме контроллеров) всегда поворачиваются по направлению движения.
Здесь наверное причина в отсутствии TASK_WAIT и TASK_STOP_MOVING. Монстр просто не успевает повернуться или проиграть ACT_TURN_LEFT/ACT_TURN_RIGHT если нужно. Ладненько, будем посмотреть. Я сейчас откачусь до предыдущих сорцев, где шаренный код монстров ещё не тронут, и буду ковырять только барника. По-грамотному уже, а то в текущей версии у меня всё на скорую руку.
Добавлено 01-12-2020 в 23:33:
FreeSlave а какие у тебя наработки в этой области?
Отправлено Next Day 01-12-2020 в 17:01:
Рад что ты продолжаешь работать над НПС
Отправлено FreeSlave 02-12-2020 в 12:55:
Ku2zoff, в области убегания монстров?
В TASK_FIND_COVER_FROM_BEST_SOUND я помимо поиска пути до укрытия сделал в качестве альтернативы просто поиск отдаленного нода. Т.к. в случае ухода от звука опасности (гранаты, например) суть даже не в том, чтобы найти укрытие, а в том, чтобы просто убежать подальше. Думаю, ты сделал нечто такое и в коде сбегания барника от врага. Тут ничего сложного, по сути тот же FindCover, но без проверки на то, что ориджин "угрозы" не увидит монстра после того, как тот встанет на ноду.
//ALERT(at_aiconsole, "Using the last resort to run away\n");
27
TaskComplete();
28
}
29
}
30
// no coverwhatsoever. or no sound in list
31
if (!TaskIsComplete())
32
TaskFail();
Если говорить в целом о поведении монстров, то я уже кое-что упоминал в предыдущей теме. Но здесь распишу то, что касается всех передвигающихся монстров, а не отдельных видов.
Добавил Monster Roaming (параметр freeroam) из Sven Co-op, с которым монстры рандомно ходят по нодам даже в idle-состоянии. В принципе может быть полезно для создания иллюзии патрулирования территории без лишних затрат.
Кстати, в HL есть патрулирование по path_track, но в очень урезанном виде - при встрече с препятствием монстр не ищет обходных путей. Это я у себя тоже исправил, плюс добавил возможность использования ожидания выставленного в path_track. И теперь в местах, где достаточно задать только передвижение монстра, использую патрулирование вместо scripted_sequence дабы монстр адекватно реагировал на окружение, ибо во время выполнения скриптов монстры реагируют только на урон.
В качестве экспериментов:
Как известно, FTriangulate в HL используется для поиска промежуточной точки, по которой можно обогнуть встреченное на пути препятствие. Я добавил возможность искать не одну, а две точки (это уже получается не триангуляция, а квадрогуляция ), что даёт неплохие результаты и особенно полезно для NPC, следующих за игроком (вас же тоже задолбали союзники, тупящие на каждом углу? )
Для союзников следующих за игроком реализована попытка подобраться к игроку как можно ближе, если монстр не смог построить путь до игрока (что случается довольно часто, стоит лишь игроку забраться повыше или пониже). В результате на crossfire барник бегает вдоль края поля перед бункером, если игрок находится на втором этаже. Побочным эффектом тут конечно является то, что монстр будет бегать за игроком вдоль стены аки примагниченный, если игрок находится с другой стороны стены. Замечу, что это сделано без использования нодов. В качестве дополнительной или альтернативной меры можно использовать что-то в духе BuildNearestRoute, но я пока этого не делал (почему-то не подумал в своё время)
Способность монстров "забывать" о своём враге, если давно его не видели, пытались-пытались добраться, да не смогли на протяжении некоего промежутка времени. Особенно актуально, если враг - игрок, т.к. ему проще всего убежать от монстра. В HL, если игрок пропустил какого-нибудь хедкраба, тот так и запомнит врага и будет весь остаток игры пытаться до игрока дойти. Монстры в HL вообще не забывают о враге до тех пор пока тот не умрёт либо не исчезнет с карты.
Сейчас в связи с последним (да и не только) думаю, чем можно было бы занять монстра в ALERT состоянии. В HL лишь некоторые монстры занимаются чем-то полезным в этом состоянии - буллсквиды ищут чего покушать, солдаты идут к трупу поверженного врага, чтобы убедиться в том, что тот умер. В остальном же монстры просто стоят и смотрят. Тут напрашиваются такие вещи как переход к последней известной позиции врага (если враг был "утерян"), исследование услышанных звуков боя (типа Investigate Sound, который по умолчанию используется только у ассассинок), и тот же freeroam, описанный выше.
FreeSlave писал: Тут ничего сложного, по сути тот же FindCover, но без проверки на то, что ориджин "угрозы" не увидит монстра после того, как тот встанет на ноду.
Нет, я сделал не так, а добавил поиск связанных нод. Это немного помогло избавиться от тупняков. Но вчера убрал кактус с тестовой карты, и барник перестал убегать, т.к. прятаться стало не за что. Я сразу смекнул что к чему, вчитался внимательнее в код и тоже решил убрать оттуда трассу, чтобы сделать просто RunAway на открытой местности.
Добавлено 02-12-2020 в 20:51:
Цитата:
Next Day писал: А куда этот код добавлять если не секрет ?
Какой код?
Отправлено Next Day 02-12-2020 в 13:57:
Ну который FreeSlave здесь написал или это просто пример.
Отправлено Ku2zoff 02-12-2020 в 14:04:
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.
Aynekko писал: гранты с дробовиками стали очень быстро стрелять
А ты убрал обе строчки с m_fSequenceFinished из DispatchAnimEvents? После внесения изменений на манер сорса, они не нужны там, т.к. должны корректно выставляться в StudioFrameAdvance и ResetSequenceInfo.
Отправлено Aynekko 02-12-2020 в 19:07:
Цитата:
Ku2zoff писал: А ты убрал обе строчки с m_fSequenceFinished из DispatchAnimEvents? После внесения изменений на манер сорса, они не нужны там, т.к. должны корректно выставляться в StudioFrameAdvance и ResetSequenceInfo.
Благодарю. Теперь как надо. Сейчас потестил, у меня гранты друг против друга выставлены по поведению, один пробегал мимо другого и тот успел его пнуть ногой. Никогда такого не видел.
Немного поясню, если вдруг непонятно, что за интервал проверки эвентов такой, от 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 в этом случае всё равно может срабатывать не вовремя.
Отправлено Дядя Миша 02-12-2020 в 20:42:
Ku2zoff тебе уже пора заводить свой блог разработчика
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Aynekko 02-12-2020 в 21:49:
Барник стал тупить у меня. Именно из-за этих изменений с анимациями.
Ситуация: стоит барник в режиме idle, я с ноуклипом и ноутаргетом спавню гранта впереди и справа от барника. Грант спавнится спиной к барнику и не видит его. Барник поворачивается к монстру, и...его зацикливает и не отпускает. Просто стоит и дрожит.
Я нажимаю на барника, его отпускает и он начинает стрелять.
Откатил изменения и больше такое не повторяется.
Я в этом мало что понимаю, поэтому не знаю, с чего может быть связано, просто решил поделиться.
Aynekko писал: его зацикливает и не отпускает. Просто стоит и дрожит.
Я нажимаю на барника, его отпускает и он начинает стрелять.
Это там где-то в GetSchedule проблема, раз после того, как поюзаешь, он очухивается - щедъюль принудительно изменяется. Почему-то он не может сделать SCHED_ARM_WEAPON, или как там это называется, когда достаёт пистолет. Ты на чистом ксашмоде делаешь, никаких изменений в монстров не вносил? Там "спаунер" для НПС есть, чтобы я смог проверить? Ситуация всегда одинаковая, в каком бы состоянии барник не был до спавна гранта? Думаю, что под халфой это может не проявиться, но всё равно попробую повторить ситуацию. И карту напиши, на которой проверяешь, стандартная или своя.
Видео записать можешь?
Добавлено 03-12-2020 в 06:23:
И есть какая ругань в консоли? Что в лог пишется?
Добавлено 03-12-2020 в 06:35:
Цитата:
Дядя Миша писал: тебе уже пора заводить свой блог разработчика
Разве что писать мысли вслух. Кое в чём я начинаю понимать и разбираться, а кое-что упускаю из виду. Будем тут в теме совместно с заинтересованными кумекать, поди чего сообразим.
К примеру, позавчера я тестировал новые добавленные щедъюли барника - ближний бой, перезарядку, прятки с врагами. Ну и короче понял, что перезарядка в идеале должна быть как у гранта - убежал, перезарядился. Не смог убежать - просто перезарядился. Сделал. Не может убежать, начинает перезаряжаться, его убивают.
Помозговал, поменял несколько условий, получил идеальный результат: кончились патроны, пытается убежать и перезарядиться. Не может убежать - перезаряжается на месте. Если враг подошёл слишком близко, то не перезаряжается, а бьёт его пистолетом. Это касаемо перезарядки. Касаемо подхода близко - если у врага здоровье больше 30, то барник в любом случае от него валит, если может. А вот если меньше 30, то он его бьёт, потому что завалит за два удара (примерно 2 секунды).
Насчёт DispatchAnimEvents я прям ХЗ. У себя проблем не заметил: и скрипты проверял, и просто работу AI. Надо бы конечно полностью пройти халфу с этим изменением и убедиться, что всё хорошо. Проблема в том, что времени жалко.
Отправлено Aynekko 03-12-2020 в 05:53:
Тут вот какая странность. У меня у барника заменная модель.
Я поставил родную модель и бага нет. С моей моделью и твоим кодом баг проявился 2 раза из трех. С родной - ни разу из 4-ех раз (условия идеальные - стоящий барник, рядом монстермейкер, который я активирую - больше на карте никого (плоская площадка с колоннами, ноды есть).
Может что-то не так с самой анимацией draw?
Добавлено 03-12-2020 в 08:51:
Я свою модель чуть редактировал, поэтому нашел оригинал и проверил. С ней тоже этот баг есть. Прикрепляю.
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 условие игнорирует последний кадр в случае нелупленных анимаций:
C++ Source Code:
if ( (pevent[index].frame >= flStart && pevent[index].frame < flEnd) ||
if (pevent[index].cycle >= flStart || pevent[index].cycle < flEnd)
11
{
12
bOverlapEvent = true;
13
}
14
}
Но с ним первый кадр тоже вроде иногда проскакивает. Буду проверять.
Отправлено KorteZZ 03-12-2020 в 11:57:
Блин, классные вещи вы делаете. Тут можно серию туторов сделать как для голды, так и для ксаша. Для мододелов было бы круто иметь продвинутых нпс. Я для себя вот про адекватных зомбачелло мечтаю)
Надеюсь, и их прокачаете
Ku2zoff, насчёт FindCover кстати. В hlsdk WorldGraph.m_iLastCoverSearch меняется прямо внутри цикла и при этом складывается с индексом для получения нода, что может привести к пропуску части нодов во время поиска подходящего. Собственно в моём FindRunAway ты можешь видеть, что я переместил эту строчку прямо перед возвращением успеха. Рекомендую то же самое сделать в FindCover.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 03-12-2020 в 15:31:
Я потестировал старый и новый вариант. Разницы не заметно, кроме того, что новый вариант перестаёт ловить последний кадр и даёт рассинхрон (звук и маззлфлеши запаздывают), если анимации быстрые. Видно на примере стрельбы грантов из автомата. Позже буду ещё смотреть. Думаю, лучше всего убрать фиксированный flInterval и m_fSequenceFinished из DispatchAnimEvents и попытаться забороть пропуски эвентов. Дело, я думаю, в частоте тчинка: gpGlobals->time + 0.1. Если как-то заставить DispatchAnimEvents вызываться каждый кадр, то проблема теоретически должна уйти.
Отправлено ncuxonaT 03-12-2020 в 16:58:
Таким способом можно починить ИИ в Паранойе?
Отправлено thambs 03-12-2020 в 17:26:
Ku2zoff
А монстры теперь умеют толкаться между собой и с игроком?
ncuxonaT писал: Таким способом можно починить ИИ в Паранойе?
По результатам тестов вышло, что ничего не починилось, кроме тупняков со скриптами (см. gruntbattledemo). В остальном ситуация усугубилась. Нужно втыкать счётчик с алертами, смотреть количество эвентов в играемой анимации и срабатываний HandleAnimEvent. Искать, в каких условиях эвенты пропускаются, и пытаться исправить. Я уже и с клиентской части дёрнул IEngineStudio.ClientEvents - тоже не то пальто. В зависимости от изменений то начало анимации корректно обрабатывается, то конец.
Из всех вариантов лучшим оказался вариант от вэлв, без фиксированного flInterval и m_fSequenceFinished в DispatchAnimEvents.
Цитата:
thambs писал: А монстры теперь умеют толкаться между собой и с игроком?
Научатся, если написать соответствующий код. Не останавливать монстра, если ему блокирует дорогу другой монстр, и двигать блокирующего.
Мне одному примеры для работы искать муторно. Если у кого вдруг есть какие-то регулярно повторяющиеся несрабатывания скриптов или поведения монстров, можете эту фигню сунуть в карту-коробку и кинуть аттачем. Я буду посмотреть и пробовать разные варианты исправлений. Должен же быть способ вылечить пропуски эвентов без фиксированного интервала.
Отправлено Aynekko 03-12-2020 в 19:20:
Ku2zoff, после фикса в диспетчере сломался монстр контроллер. Стреляет пару раз и атака прекращается навечно. Посмотри, что там. Я пойду гляну что там с анимациями.
Хм, поменял в анимации атаки первый эвент с 0 на 1 кадр, все равно. Постреляет пару раз и перестает.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 04-12-2020 в 13:11:
Закончил барника. Осталось только сделать ему дробовик. Тут придётся повозиться с анимацией бега, т.к. та, что есть в Zombie Edition выглядит как картон из Terminator 3: War of the Machines.
Отправлено Lev 04-12-2020 в 13:22:
Ku2zoff Да, впечатляет, однозначно лучше чем было в оригинале.
Отправлено Chyvachok 04-12-2020 в 15:10:
Цитата:
Ku2zoff писал: та, что есть в Zombie Edition выглядит как картон из Terminator 3: War of the Machines.
Я и забыл какие они там, теперь вспомнил чем они мне не угодили, те что в БХЛ вроде тоже не супер-пупер, но вроде не такие картонные. Из оружия еще можно было бы версию с Магнумом сделать, ну и автоматом, типа у солдата отобрал.
Кстати знаком мод Hard-Life? Мод еще делается, типа более усложненная халва, зомбари бегают, крабы передвигаются прыжками, но не это меня заинтересовало, там классно расширили барников, помимо разного оружия им добавили много разных новых голов, плюс есть варианты с жилетом и без, и помимо каски они могут носить кепку, этого барникам не хватает, у солдат и ученых 4 варианта головы, а у барника одна. Плюс мне там понравились переделки карт из халвы, из расширили, причем неслабо.
Еще бы солдатам было бы неплохо пофиксить их знаменитый тактический маневр - положить гранату на пол и взорвать себя.
Отправлено Lev 04-12-2020 в 15:32:
Цитата:
Chyvachok писал: Еще бы солдатам было бы неплохо пофиксить их знаменитый тактический маневр - положить гранату на пол и взорвать себя.
Плюс 1, это реально мерзотно выглядит)
Отправлено Aynekko 04-12-2020 в 15:48:
Цитата:
Chyvachok писал: Еще бы солдатам было бы неплохо пофиксить их знаменитый тактический маневр - положить гранату на пол и взорвать себя.
Это наверное было первое что я полностью выпилил, когда ими занялся. Зачем это вообще было сделано, не очень понятно)
А я тут осваиваю анимирование во фрагмоушене. Таки удобнее, чем в милке.
Отправлено Aynekko 05-12-2020 в 05:55:
Короче с контроллером там все очень плохо. У него прописаны в коде таски, что-то связано с эвентами анимаций и временными зависимостями. Полагаю, в этом проблема, что они не стреляют. Я не смог побороть.
В общем пока вернусь на старый код.
Там методика такая, сначала надо открыть 2 модели, одна которую надо посадить на скелет, и вторая та что с нужным скелетом, потом в режиме анимации надо нужную модель подогнать в ту же позу и пропорции что у модели с нужным скелетом, плюс можно использовать Scale в анимации, полезно к примеру если длина рук разная, правда нужно юзать Scale тот что во вкладке анимации, правда он увеличивает-уменьшает размер по всем координатам, но можно нажать два раза по названию анимации во вкладке, когда нужный размер по длине есть, там откроется окно с кадрами анимации, в виде кружков, найти нужную кость, нажать на кружок где Scale и вручную поставить 1 у не нужных координат, чтобы рука была-длинее-короче, но имела ту же толщину.
Потом после того как модели обе в одинаковой позе, можно удалить модель с нужным скелетом, оставив ту что подгоняли, экспортировать ее через Export Pose, именно Pose нужен, заново открыть обе модели, с нужным скелетом и ту экспортированую в нужной позе, и там можно перецепить кости, там сверху нарисована кость с желтой стрелкой, выбрать модель, нажать на нее, появится окошко, где переназначить кость, сохранив ту же привязку, надо в самой сцене выбрать кость куда надо привязать, в менюшке откуда надо привязать, и нажать на Set, причем так можно перецеплять и даже мягкую привязку, но ее в 1 Халве все равно нет. Ну и после этого можно удалить уже не нужные кости от привязываемой модели, загрузить анимацию, и там же посмотреть насколько нормальная вышла привязка и сразу подправить.
Отправлено Ku2zoff 05-12-2020 в 09:00:
Chyvachok да, я делал так перепривязку рук, Export Pose очень классная штука. Не разобрался правда, что за инструмент Inverse Kinematics, как им пользоваться и что он делает. На сайте фрагмоушена нет толком никакой статьи, обучающей, как работать.
Цитата:
Aynekko писал: В общем пока вернусь на старый код
Ты смотрел последнее видео с барником? Там старый код. Иногда подтупливает, но не сильно. Самые большие задержки из-за пауз в щедъюлях и прерывания тасков по bits_COND_BLABLABLA. Это надо просто знать, что и где убрать или сократить, или навтыкать алертов и читать консоль. Стоило мне убрать условие прерывания bits_COND_NEW_ENEMY и slBarneyTakeCoverFromEnemy, и он стал без проблем сваливать от противников. И вот таких вот мелких косячков в коде AI дофига. Ну вот согласись, если он сваливает от врага, зачем ему останавливаться, если он увидел ещё одного?
Отправлено Chyvachok 05-12-2020 в 09:27:
Цитата:
Ku2zoff писал: Inverse Kinematics, как им пользоваться и что он делает.
Эта штука нужна чтобы когда например двигаешь ладонь и вся рука сгибалась вместе с суставами, попробуй зажать Ctrl и нажать правой кнопкой мыши на кости UpperArm и подвигать ладонь, но во Фраге она хуже в чем то же максе, в максе можно этот контролер прицепить к чему-то, к примеру кости оружия и магазина, и рука сама будет следовать за костью сгибая суставы как надо.
Еще из полезных вещей есть Animation Link, он находится в вкладке Schemes, там окошко сбоку где есть вкладки анимаций, текстур и прочего, эта последняя, там изначально Root выбран, ей можно скажем так заставить одну кость следовать за другой, к примеру чтобы при сдвигании руки за ней шел магазин, там надо только поменять режим на Grab, выбрать нужные кости, и когда включаешь ее на определенном кадре анимации, оно запоминает позицию этих двух костей именно такую как в этом кадре, и при попытке сдвинуть "главную" кость оно будет само сдвигать дочернюю, плюс нажав второй кнопкой мыши на ней можно выбрать галку Apply to all frames, полезно к примеру чтобы прицеплять анимации idle и анимации стрельбы от одной модели к другой, например у некоторых моделей в анимации idle нету движения, можно ее прицепить от другой модели прицепив всю модель к кости оружия модели у которой есть idle анимация с движением.
Отправлено Ku2zoff 05-12-2020 в 09:33:
Цитата:
Chyvachok писал: ей можно скажем так заставить одну кость следовать за другой
Вот это я вчера весь вечер искал, чтобы руку барника зафиксировать на цевье дробовика. Видел же гифку? Там левая рука елозит. Покадрово её поправлять - страшный гемор. Спасибо за подсказку. Попробую во фрагмоушене всё-таки делать. Он легковесный и без проблем имортит/экспортит smd. А то я уже блендер скачал. Как прочитал, какая там навигация в 3D виде, у меня возник вопрос "Чо? шифт + скм?" Но это фигня. А вот корявый импортёр smd, который периодически выдаёт ошибки - зло.
Отправлено FreeSlave 05-12-2020 в 10:23:
Цитата:
Ku2zoff писал: Ну вот согласись, если он сваливает от врага, зачем ему останавливаться, если он увидел ещё одного?
Я думаю, в этом есть смысл, если он встретил другого противника в том месте, куда он хотел убежать. Убегает он, допустим от зомби, придёт в комнату, где стоят агрунты и будет вести себя так, будто их там и нет
Проблема в том, что AI не отслеживает сразу несколько противников (хотя может вести список прошлых, но на кондишенах это не отображается).
bits_COND_NEW_ENEMY это на самом деле должен называться bits_COND_NEW_BEST_ENEMY или bits_COND_BEST_ENEMY_UPDATED. В случае с убеганием от врага нужно другое условие, которое бы определяло, что новый противник - действительно новый, а не один из тех, кого монстр видел ранее, но кто не является "лучшим" врагом. Или даже условие, которое определяет, что новый враг находится достаточно далеко от прежнего. В общем, тут надо поразмыслить.
FreeSlave писал: Проблема в том, что AI не отслеживает сразу несколько противников
В сорсе отслеживает. Там целый класс CAIEnemies. И итератор AIEnemiesIter_t для их перебора. Ну, скажем, в халфе можно сделать m_hEnemies[MAX_ACTUAL_ENEMIES]. И вместо PushEnemy и PopEnemy как-то по-другому их перебирать. Я думаю, что штук 8 было бы вполне достаточно мониторить. И было бы полезно. Я вот завёл bits_COND_ENEMY_TOOCLOSE, чтобы монстр валил от врага, если тот близко. Но он валит именно от m_hEnemy. Если второй подошёл сзади - трындец:
Добавлено 05-12-2020 в 17:31:
Цитата:
FreeSlave писал: и будет вести себя так, будто их там и нет
Один из грантов станет для него m_hEnemy, и он отреагирует.
Отправлено Дядя Миша 05-12-2020 в 10:33:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 05-12-2020 в 10:35:
Дядя Миша я пока забил. Занялся самим AI. К эвентам потом наверное вернусь.
Отправлено FreeSlave 05-12-2020 в 10:58:
Цитата:
Ku2zoff писал: Один из грантов станет для него m_hEnemy, и он отреагирует.
Это уже после того, как он дойдёт до укрытия. Если ты убрал из шедули прерывание по bits_COND_NEW_ENEMY, то барник и не будет получать врагов до тех пор, пока эта шедуля играется.
Ku2zoff писал: Вот это я вчера весь вечер искал, чтобы руку барника зафиксировать на цевье дробовика. Видел же гифку? Там левая рука елозит. Покадрово её поправлять - страшный гемор.
Это не совсем то, Animation Link цепляет отдельную кость, он не сгибает суставы как инверсная кинематика, а во Фраге нету какой-то объединенной версии, это в 3ДС Максе можно сделать, создать там инверсную кинематику, при ее создании на месте кости руки появится обьект Solver, который можно тягать и за ним рука будет сама двигаться сгибаясь, и его уже можно прицепить к оружию.
Отправлено Ku2zoff 05-12-2020 в 17:11:
Цитата:
Chyvachok писал: во Фраге нету какой-то объединенной версии
Эти инструменты только по отдельности работают? Я пробовал ИК, сочетается с другими инструментами скелетной анимации. То есть, Rotate/Translate применяешь на дочернюю кость, и вся цепочка до родительской, указанной в ИК, поворачивается и сгибается как ты описал. Если совсем не работает, тогда сделаю в блендере, для него есть туторы по этой теме. Макс качать и ставить такое себе удовольствие: больно жирный он, да ещё и крякать надо.
Добавлено 06-12-2020 в 00:11:
Ну вот, в блендере совсем другое дело:
Отправлено ncuxonaT 05-12-2020 в 17:26:
Ku2zoff сделай рассинхрон в качении рук и тела
Отправлено Ku2zoff 05-12-2020 в 18:02:
ncuxonaT как плечи качаются, так и качаются остальные руки. Лень мне ковыряться. Типа дышит, пусть будет как есть.
Добавлено 06-12-2020 в 01:02:
Вообще, это всё на пробу сделано. Буду переделывать. При идле и ходьбе всё равно левая рука неприятно елозит по цевью, бросается в глаза. Да и углы сгиба и положение рук надо бы подглядеть у других моделей, где есть двуручное оружие.
Отправлено FreeSlave 06-12-2020 в 09:45:
Цитата:
Ku2zoff писал: Будем посмотреть. Возможно, придётся действительно заводить список врагов.
Я ещё подумал на эту тему. В HL же есть разные градации неприязни. Если барник в качестве врага получит кого-то кого он "ненавидит" (HATE), то будет игнорить всех, к кому степень неприязни ниже (DISLIKE), соответственно и твои проверки на TOOCLOSE скорее всего не сработают (ну смотря как ты написал). Т.е. может возникнуть ситуация, когда ненавидимый враг стоит далеко, а другой подходит вплотную к барнику, и тот убегать не станет.
В общем, ещё один аргумент в пользу смены системы.
Закончил барника с дробовиком. Нужно немного отполировать анимацию стрельбы и сделать анимации поворотов направо и налево.
Отправлено 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 ) )
2
{
3
ASSERT(!HasConditions(bits_COND_SEE_ENEMY));
4
SetConditions( bits_COND_ENEMY_OCCLUDED );
5
}
Это как было. Здесь я закомментировал строчку SetConditions.
Далее, идут условия:
if (m_flLastTimeObservedEnemy + 3 <= gpGlobals->time)
SetConditions( bits_COND_ENEMY_OCCLUDED );
Теперь в течении трех секунд вражина не будет считать, что враг исчез. Надо тестить еще, но каких-то предпосылок к поломке чего-либо я не вижу - условие простецкое.
Aynekko, и откуда ты взял m_flLastTimeObservedEnemy? Это же не стандартная переменная.
По поводу поведения солдата: надо смотреть, что ему прерывает шедулю следования и какая выставляется. По тому, что я вижу, bits_COND_ENEMY_OCCLUDED прерывает атаку, но не движение. Смену шедулей можно отследить. Valve даже оставила отключенный код с алертами в ChangeSchedule.
У тебя с гитхаба, ага, большое спасибо. Теперь у меня тоже нпс забывают свою цель, выставил им оптимально 15 секунд, вроде норм.
Я почему-то думал, что она стандартная, уже и забыл.
Цитата:
FreeSlave писал: bits_COND_ENEMY_OCCLUDED прерывает атаку, но не движение
Ну вот без временного отрезка в 3 секунды он просто теряет игрока, потом я тут же выхожу из-за угла и он начинает снова - остановка, проверка атаки, потом стрельба. Т.к. я туда-сюда быстро хожу, он просто не успевает и "застревает" в этих щедулях.
Aynekko писал: У тебя с гитхаба, ага, большое спасибо.
Ну раз используешь мою кодовую базу, то жду багрепортов, а то и пуллреквестов
Цитата:
Aynekko писал: он просто теряет игрока, потом я тут же выхожу из-за угла и он начинает снова - остановка, проверка атаки, потом стрельба
Т.е. ты всё-таки говоришь об остановке во время атаки, а не во время движения. Да, есть такая проблема. Я даже волтигорам убрал bits_COND_ENEMY_OCCLUDED из шедули атаки, потому что анимация создания заряда довольно долгая, да и сам заряд летит не мгновенно, так что такая проверка ни к чему. Раз уж начала - пусть стреляет. О том, чтобы применить нечто подобное к другим монстрам, я не думал. Хотя стоило бы.
Да тут вроде все понятно, через 15 секунд они восстанавливаются на позицию вылетал из карты ноуклипом и смотрел с выставленными алертами. А больше я ничего у тебя не брал. У тебя там еще есть ходьба в состоянии idle вроде как, но я не стал вникать - мне в общем-то не нужна эта фича.
Цитата:
FreeSlave писал: убрал bits_COND_ENEMY_OCCLUDED из шедули атаки, потому что анимация создания заряда довольно долгая, да и сам заряд летит не мгновенно, так что такая проверка ни к чему. Раз уж начала - пусть стреляет.
Не думаю, что стоит совсем уж убирать. Попробуй как у меня сделать может? И то, в эти три секунды они могут в стену стрелять, т.к. враг якобы все еще здесь…но это лучше, чем тупняк на месте. В большинстве случаев это выглядит как подавляющий огонь, что тоже здорово. Я у себя еще сделал рандом у солдат при occluded, 60% шанса кинуть грену и 30% range attack1. С этой новой проверкой этот рандом можно и убрать будет.
Насчёт прерываний анимаций атаки. Шедули атаки же прерываются ещё и условием bits_COND_NEW_ENEMY. По-моему, это тоже плохо. Монстр начинает анимацию, получает другого врага (который, допустим, во время проигрывания анимации оказался ближе, чем предыдущий) и анимация прерывается. А ведь враг может сменяться быстрее, чем проходит время анимации, соответственно монстр может вообще стоять и постоянно прерываться. Наверно было бы лучше, если б во время тасков атаки монстр не переключался на других врагов.
На самом деле вышеописанная ситуация может случиться не только с анимациями, но и с поворотами - пока монстр поворачивается к одному врагу, враг может сменится, и монстр начнёт поворачиваться к другому, и так по кругу.
В общем, нужно ввести какую-то меру против частого переключения между противниками. Можно было бы вообще убрать прерывание по bits_COND_NEW_ENEMY для шедулей атак, но это может привести к ситуации, когда монстр с дистанционной атакой перестанет обращать внимание на противников, которые подошли ближе к нему и продолжать стрелять по врагу на расстоянии.
Цитата:
Aynekko писал: Да тут вроде все понятно, через 15 секунд они восстанавливаются на позицию
Я сделал, чтоб они к последней известной позиции врага пытались пройти. Не забудь кстати эту переменную в save/restore добавить, а то я отдельным коммитом это поправил.
Ещё по идее надо подправить взаимодействие с PushEnemy и PopEnemy. В списке старых противников может оказаться тот же противник, что был и в m_hEnemy до того, как монстр о нём "забыл", и PopEnemy снова вытащит его же в качестве противника. Т.е. надо либо не допускать одновременного нахождения одного и того же монстра и в m_hEnemy и в m_hOldEnemy, либо вычищать его из списка при забывании.
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
2
3
EHANDLE m_hOldEnemy[ MAX_OLD_ENEMIES ];
4
Vector m_vecOldEnemy[ MAX_OLD_ENEMIES ];
И в коде монстра соответственно PushEnemy и PopEnemy. Скажи пожалуйста, почему я, который в коде монстров вообще не ковырялся, об этом в курсе, а ты, который уже много лет улучшает AI до сих пор об этом не знаешь. Мне прямо страшно что ты там мог натворить.
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:
А как ты представляешь, чтобы монстр одновременно со всеми разбирался?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 10-12-2020 в 14:42:
Для этого и нужны приоритеты. Можно модифицировать старую систему, чтобы при определённых условиях монстр не отправлял m_hEnemy в список старых врагов. Я пока не знаю, как лучше поступить. Не хочется трогать стандартный код монстров. Заведу новый класс-наследник и буду работать с ним. Как раз у меня барник - первый кандидат на "поумнение". Посмотрим, что можно сделать. Я пока на это подзабил и сделал прикольную квестовую составляющую с предметами, которые надо носить в определённое место. Как только доработаю - вернусь к коду монстров.
Выяснилось, что возможен баг, когда 2 монстра (воюющие против друга) могут залипнуть на месте, при этом идет loop с бесконечным вызовом TASK_FACE_ENEMY. Немножко переделал, так вроде баг ушел.
Было:
C++ Source Code:
1
if ( !FVisible( pEnemy ) )
2
{
3
ASSERT(!HasConditions(bits_COND_SEE_ENEMY));
4
SetConditions( bits_COND_ENEMY_OCCLUDED );
5
}
6
else
7
ClearConditions( bits_COND_ENEMY_OCCLUDED );
Стало:
C++ Source Code:
1
if ( !FVisible( pEnemy ) )
2
{
3
ASSERT(!HasConditions(bits_COND_SEE_ENEMY));
4
if (m_flOcclusionTime + 3 <= gpGlobals->time)
5
{
6
SetConditions( bits_COND_ENEMY_OCCLUDED );
7
m_flOcclusionTime = gpGlobals->time;
8
}
9
}
10
else
11
{
12
ClearConditions( bits_COND_ENEMY_OCCLUDED );
13
m_flOcclusionTime = gpGlobals->time - 2;
14
}
Завел новую переменную, чтобы ничего другого не сломать ненароком, ее в сейврестор конечно же добавить не забыть. Результат тот же и баг пока не наблюдался.
В else я не совсем уверен, но мне нравится результат.
Я снова в эфире. Веду вещание с Asus P7H55-M LX + Intel Core i3 540 и 4 GB DDR 1333. Почти неделю ни над чем не работал, соскучился по моддингу.
Отправлено PLut 27-12-2020 в 22:42:
Ku2zoff С возвращением! Надо будет попробовать этот код в Бейс Дефенсе
P.S. Найс платформа, очень дешевое железо на нее, у меня где-то валялся серверный аналог i7 первого на эту платформу - Xeon X3440 (только мой экземпляр, кажется, перегретый). Сейчас он рублей 800 стоит.
PLut железо не моё - клиентское. Просто ребята с жадности не захотели покупать БП и мать в магазине, когда матери ещё были. Ну а с рук нормальных БП никто не продавал. В итоге, железки остались у меня больше чем на год. Странным образом материнка расчухалась и у неё пропал дефект - автостарт после выключения (была пробита в грозу через сетевую плату). Вот теперь временно сижу на этой платформе. По ощущениям ай3 540 немного уступает моему FX8350, но не критично. А вот по памяти лажа. Мои две планки по 4Gb 1600 Мгц она не может схавать - потолок по частоте у неё 1333 Мгц.
Отправлено Дядя Миша 28-12-2020 в 11:04:
Цитата:
Ku2zoff писал: Странным образом материнка расчухалась и у неё пропал дефект
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 29-12-2020 в 09:43:
Цитата:
Дядя Миша писал: отлежалась, бывает.
Бывший хозяин материнки с этого в шоке. Он мне её отдал как металлолом. Я её поставил одним ребятам нерусской национальности, т.к. очень просили, чтобы пека работала. Сразу сказал - автостарт это плохо, максимум на неделю, а потом как хотите, но надо брать новую. Тогда в ДНС они ещё были. В итоге, жадность их сгубила. Привезли мне это чудо где-то через год, с двумя мёртвыми винчестерами на 1 и 2 тб и отъехавшим БП. И вот ещё год лежало, хотя тогда матери на 1156 были в продаже. А тут у меня случился конфуз: GA-970A-DS3 отошла в мир иной. Я пять дней сидел с планша, но это не то пальто. Выкопал винт в кладовке, накатил винду, чтоб только погамать. А оно раз, и норм работает. Короче, конвертнул ССД из GPT в MBR и завёл свою привычную систему на этом железе. Три дня - полёт нормальный. А я ведь уже хотел просить знакомого выпаять сетевой контроллер, может быть помогло бы от автостартов, скорее всего он в кз. А оно само его выпаяло, наверное совсем прогорел после нескольких включений. Наколхозил охлад из куска пластмассы и радиатора от 1156 + вентилятор от 775 - родной так страшно свистел из-за стёртого подшипника - уши болели. Сегодня первый хозяин материнки подогнал мне блатной охлад от Cooler Master на этот сокет, с инвентарным нумером 051207 (Спасибо Почте России). Осталось вспочинить охлад на видюхе - тоже свистит.
Отправлено Дядя Миша 29-12-2020 в 09:54:
Полевики обладают таким свойством - восстанавливаться после кратковременного большого пробоя. Им на это нужен полный покой около двух недель. Конечно то, что пробито намертво, уже не оживёт, но то, что просто зацепило не до конца - будет работать. Лотерея конечно.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 29-12-2020 в 10:07:
Цитата:
Дядя Миша писал: Им на это нужен полный покой около двух недель.
Так ведь ситуация вот какая: я взял винт, который не жалко, собрал машину. Запустил. Автостарт был. Накатил винду - автостарт был. Начал устанавливать все игры и вообще настраивать, чтобы было удобно. Потом пыль вытер, термопасту сменил, ну как обычно. Автостарт был. Включал/выключал Onboard LAN - ситуация не менялась... Потом воткнул китайскую вай-фай плату с алика и какую-то древнюю реалтековскую сетевуху, ещё раз вытер пыль - вуаля, автостарт пропал.
Отправлено Aynekko 14-01-2021 в 12:37:
У нпс есть такое свойство иногда - тупить пару секунд. Часто бывает, что нажимаешь юз на него, он говорит "окей, пошли" и стоит. Игрок от него отходит уже прилично так, и нпс только через 3 секунды сообразит, что ему вообще-то идти надо. Поворачивается и бежит. В подавляющем большинстве случаев нпс срабатывает сразу и бежит за тобой.
Я сначала думал, что это из-за того, что ему нужно доиграть анимацию idle, а потом смотрю - неа. Анимация играет, но он поворачивается и идет.
Есть у кого идеи, куда копать надо? Может это все те самые TASK_WAIT виноваты?
Сиквенс Финишед не всегда срабатывает поидее. Раза с третьего-пятого.
Впрочем, вы вообще уверены, что хотите шустрых NPC?
Если их довести до ума, они игрока выносят на раз.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 14-01-2021 в 14:42:
Дядя Миша в сорсе же шустрые, но не выносят
Отправлено Ku2zoff 14-01-2021 в 15:28:
Цитата:
Дядя Миша писал: Если их довести до ума, они игрока выносят на раз.
Скилл.цфг можно подкрутить и уменьшить урон. Есть такие моды, где и тормозные НПС выносят игрока на раз-два. Название не помню, какая-то убогая гадость, где мы в роли спецназовца пробираемся на вражескую базу и по стелсу выносим вражын. Из оружия есть г36 и ещё бег на шифт. Игрок там действительно спецназ-овца, помирает с двух попаданий в пятку. Реализм это конечно хорошо, но палочку перегибать не стоит, иначе народ будет плеваться. Много народу в DoD играет и играло? По сравнению с кс или даже тф - ничтожно мало. Вон, хороший пример баланса, деус эксы. Игрок вроде и аугментации имеет, и вооружён хорошо, а по-думовски не разгуляешься, завалят. Но если подходить к прохождению с умом, можно порой и против толп воевать.
Отправлено Дядя Миша 14-01-2021 в 16:16:
ncuxonaT ну вот в сорсе как раз поисправляли все анимационные баги.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 14-01-2021 в 16:56:
Цитата:
Дядя Миша писал: в сорсе как раз поисправляли все анимационные баги
Я сравнивал код, портировал в халфу. Собсно, эта тема поэтому и открыта. Трабла в том, что эвенты перестают вовремя отлавливаться, если использовать код из сорса. Маззлфлеши опаздывают, стрельба тоже. Потому что пропадает привязка к gpGlobals->time и частоте тчинка монстра. Есть у меня одна идея, но не знаю, сработает или нет. Надо заставить монстра тчинкать не 10 раз в секунду, как в оригинале, а каждый кадр. pev->nextthink = gpGlobals->time. Ну и вызывать StudioFrameAdvance и DispatchAnimEvents. А всё остальное вынести в отдельную функцию, чтобы по-старинке вызывалось каждые 0.1 секунды. Нельзя всё ускорять - RunAI ломается. Хотя в сорсе частота тчинка тоже 0.1 секунды, и ничего не тупит. Что-то я упустил. Там довольно много кода, куча экземпляров StudioFrameAdvance и DispatchAnimEvents: для CBaseAnimating, CBaseAnimationLayer, CBaseAINPC, CBasePlayerWeapon и т.д. Ч0рт ногу сломит, короче. Чем новее сорс сдк, тем больше там наплодили функций. Самая читаемая, на мой взгляд версия - 2007. В бете много недописанного, а в 2013 легко заблудиться. Собсно, не удивительно, почему движок в последних версиях весит под три сотни мегабайт: так всё усложнено и засрано там.
Отправлено Дядя Миша 14-01-2021 в 17:29:
Цитата:
Ku2zoff писал: Маззлфлеши опаздывают, стрельба тоже
в сорсе и голдсорсе кадр начинается в разных местах.
Есть там одно различие, вот как раз ровно на один кадр. Но это надо фундаментально понимать принципы работы и смотреть в движке.
Цитата:
Ku2zoff писал: Собсно, не удивительно, почему движок в последних версиях весит под три сотни мегабайт
экспериментов много было.
Добавлено 14-01-2021 в 20:29:
Они там даже для мира воксельную физическую сетку построили. Интересно сколькож она жрёт памяти.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 15-01-2021 в 08:40:
Так. Я всё понял. Теперь понятно, зачем вальве привязка к gpGlobals->time в голдсорсовском коде. Чтобы скомпенсировать этот сдвиг. Сначала тчинк - потом прибавление кадра. Ладно, будем подумать.
Отправлено Дядя Миша 15-01-2021 в 09:02:
Цитата:
Ku2zoff писал: Теперь понятно, зачем вальве привязка к gpGlobals->time в голдсорсовском коде. Чтобы скомпенсировать этот сдвиг.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Sigurth 29-03-2021 в 16:30:
Вот я кажется починил. Конкретно починил двойное срабатывание ивентов. Также нормально воспроизводятся ивенты на первом и последнем кадрах анимации. Потестировал уже на всех монстрах. Были кое-какие проблемы с контроллерами на уровне с Нихилантом, но остальные вели себя нормально. Остальных также пофиксил. Так как нахожусь сейчас не дома, а в командировке, то исходников мода нет, попробую на рабочем ноуте по памяти на чистом ХЛСДК воспроизвести свои действия и выложить в виде скомпиленного мода + тутор с пояснениями. Ну и отловим баги. Основывался на том, что привязка ко времени вообще не нужна. Проблема была в проклятых флоатах в pev->frame, которые даже при строгом неравенстве все равно на краях интервалов воспроизводили ивент дважды. В стандартном коде, мало того, что была эта проблема, так еще и из-за этой привязки к gpGlobals->time интервалы flStart и flEnd залезали друг на друга. На примере хуман гранта: должно быть [0,2) -> [2,4), а получалось [0.000000, 2.000000) -> [1.999996, 3.999992), из-за чего ивент на втором кадре проигрывался два раза. Поэтому они и стралеют по 4 пули, а не по 3, как должны. У меня они теперь стреляют как надо. Еще и скедьюлы подредактировал, что вообще резвые стали, затупки происходят крайне редко. Короче, сейчас в командировке делать нечего, поэтому попробую воспроизвести свой код и сразу выложу сюда мод и тутор.
__________________ Никогда не поздно сделать мод под хл1
Отправлено Aynekko 29-03-2021 в 16:38:
Цитата:
Sigurth писал: Вот я кажется починил. Конкретно починил двойное срабатывание ивентов.
Если ты все это сделаешь, я буду безмерно благодарен. Это будет тот самый рывок, скачок и прорыв, которого ждет вся страна!
Такс, я немного увлекся и сделал все прямо сейчас. Так как уже дико хочу спать, пока что выложу скимпиленный мод без исходников, а уже завтра-послезавтра тутор + исходники, так как мысли не вяжутся в единую историю, и выйдет лажа, а не тутор. Пока что проверьте всех монстров на разных фпс, и особенно скриптовые сценки. У моем моде на домашнем компе все вроде нормально работает, этот я по памяти писал. Если найдете баг, пишите, значит ,я что-то упустил. В консоль будет писаться каждый вызов функции GetAnimationEvent при найденном ивенте. Пока редактировал только код CBaseAnimating, скедьюлы монстром не трогал, это уже либо завтра-послезавтра, либо вы сами, так как там не трудно. Просто TASK_WAIT не 2 секунды, а 0.5 например, ну и где-то их вообще надо будет удалить.
__________________ Никогда не поздно сделать мод под хл1
Отправлено Sigurth 30-03-2021 в 04:39:
Сам нашел баг, хаундаи не могут атаковать игрока, тужатся, пытаются, но не получается у них волну выдавить. Эту проблему я уже решал, только не помню как, Пока жду еще баги, сегодня их поисправлю.
Добавлено 30-03-2021 в 11:17:
Баг с хаундаями исправлен. Если еще баги не найдутся, постараюсь сегодня вечером выложить мини-тутор + исходники + скомпилированный мод
Добавлено 30-03-2021 в 11:36:
Версия с исправлениями
Добавлено 30-03-2021 в 11:39:
Желательно потестировать и на ксаше тоже, у кого есть такая возможность
__________________ Никогда не поздно сделать мод под хл1
Отправлено Ku2zoff 30-03-2021 в 06:21:
Последняя стим-халфа, 60 фпс, вертикальная синхронизация включена. У гранта, стреляющего из дробовика, маззлфлеш появляется только при первом выстреле. Когда я пытался вспочинить, было такое же, но ещё и звук отставал. С оригинальной серверной дллкой вспышки от выстрелов появляются когда надо, лишь изредка пропускается 1 выстрел из 5.
Отправлено Sigurth 30-03-2021 в 06:27:
Ku2zoff У меня при тех же условиях на стандартной ДЛЛ проигрывается только первый маззлфлеш, остальные игнорятся. В моей ДЛЛ абсолютно точно так же - первый есть, остальных нет.
Маззлффлешы это клиентские ивенты, я их не трогал, они и не должны были менять свое поведение, кроме небольшого рассинхрона. Насколько я знаю, функция их отлова вшита в движок.
__________________ Никогда не поздно сделать мод под хл1
Отправлено Aynekko 30-03-2021 в 08:56:
С маззлфлешами у меня все окей (скачал клиент хлдм орг, там подменил хл.длл). Вроде с монстрами все нормально - в плане атак и прочего. Но контроллер сломан. Выпускает 2 шара, а потом просто летает и уже никогда не атакует.
Добавлено 30-03-2021 в 11:56:
Цитата:
Ku2zoff писал: У гранта, стреляющего из дробовика, маззлфлеш появляется только при первом выстреле.
Ток щас понял, что речь шла именно про дробаш. Да, есть такое. С новой длл маззлфлеш только первый. С оригинальной длл он есть при каждом выстреле и, кажется, грант чуть медленнее стреляет (мб показалось).
Действительно, маззлфлеши в оригинале есть, хоть иногда и проскакивают, а у меня стабильно отсутствуют. Но это мне не казалось большой проблемой, я бы даже не заметил этого. А вот что делать с контроллерами я не помню. У меня они точно нормально работали, хотя у меня закрались сомнения, что нет. Нихилант тоже стал вести себя не совсем адекватно. Значит, я что-то сделал не так, потому что Нихилант у меня точно работал нормально, я перед отъездом запускал карты Зена в своем моде и убивал Нихиланта, все было ок. Сегодня-завтра еще покапаюсь, пока что нет смысла что-либо выкладывать.
Добавлено 31-03-2021 в 01:16:
Контроллеров пофиксил (причем не трогая его собственный код), Нихиланта тоже, вроде бы монстры все теперь работают, как надо. Проблему с маззлфлешами не решал, но кажется знаю, куда копать. Посмотрите на поведение барни, некоторые его выстрелы будто не интерполируются, и маззлфлеши отсутствуют. А когда интерполируются, то и маззлфлеши есть. Короче, надо идти на клиент, и смотреть там. Кидаю исправленную версию, проверяйте.
__________________ Никогда не поздно сделать мод под хл1
Отправлено Aynekko 30-03-2021 в 18:56:
Контроллеры кажись пришли в норму. С маззлфлешами все еще беда есть, да. На барника посмотрел, выстрелы местами кажутся резкими что ли, наверное это имеется в виду.
Мне лично эти немного резкие движения совсем не мешают, маззлфлеши, которые и раньше глючные были, я тоже не замечал, пока вы не сказали) В клиентском коде моделей я совсем не шарю, поэтому передам эстафету кому-нибудь другому. Могу лишь сказать, как поступил бы я. Отлавливал бы клиентские ивенты на сервере (где они теперь отлавливаются хорошо) и отправлял бы какую-нибудь мессагу, которая и рисовала бы маззлфлеш на клиенте. Могу ради эксперимента так сегодня сделать
__________________ Никогда не поздно сделать мод под хл1
Отправлено Ku2zoff 31-03-2021 в 06:18:
Цитата:
Sigurth писал: Мне лично эти немного резкие движения совсем не мешают
m_fSequenceFinished иногда выставляется в TRUE раньше конца анимации, скорее всего. Дёрганье выглядит некрасиво.
Цитата:
Sigurth писал: Отлавливал бы клиентские ивенты на сервере (где они теперь отлавливаются хорошо) и отправлял бы какую-нибудь мессагу, которая и рисовала бы маззлфлеш на клиенте.
Костыль. Лучше вынести из движка в клиентку содержимое IEngineStudio.StudioClientEvents, и заменить вызов этой функции на свою, которая будет корректно работать.
Добавлено 31-03-2021 в 11:02:
Цитата:
Sigurth писал: В клиентском коде моделей я совсем не шарю, поэтому передам эстафету кому-нибудь другому.
Когда выложишь код серверной части, я посмотрю, что ты там изменил, и попробую покумекать. Не трогай клиентскую часть, допиливай то, чем занимаешься. Результат хороший - монстры уже не протупливают на сменах активностей.
Добавлено 31-03-2021 в 11:11:
Насчёт маззлфлешей. Не видно только спрайта. Длайт рисуется при каждом вызове. Или это pev->effects =| EF_MUZZLEFLASH, что создаёт елайт. Надо проверить. Клиентских эвентов немного: 5001, 5011, 5021, 5031 для маззлфлешей, 5002 для искр и 5004 для звуков. Проще всего декомпильнуть модель, поменять проблемный эвент на другие, и проверить, в отлове эвентов дело, или в чём-то другом.
Добавлено 31-03-2021 в 12:56:
Сделал StudioClientEvents в дллке. Действительно, проблема только со спрайтами маззлфлешей. Клиентские елайты создаются. Причём, маззлфлеши проскакивают и на дллках со стандартным кодом отлова эвентов, как серверных, так и клиентских. Кажется, эта проблема наблюдается ещё и у Aynekko в ксашмоде. Значит, дело во времени жизни маззлфлешей: они появляются в самом конце кадра и не успевают толком отрисоваться, т.к. в начале следующего исчезают. Ничего не нужно тащить в клиент, достаточно просто заменить gEngfuncs.pEfxAPI->R_MuzzleFlash на gEngfuncs.pEfxAPI->R_TempSprite с увеличенным временем жизни до 0.05, например.
Отправлено Aynekko 31-03-2021 в 06:31:
Цитата:
Ku2zoff писал: Кажется, эта проблема наблюдается ещё и у Aynekko в ксашмоде
Там решил тем, что я в движке у маззлфлеша поставил die=0.05, а было 0.01. Не знаю, есть ли в коде халфы возможность отредактировать эти функции. В параное 2 стоит 0.015 к примеру.
Только спрайт все еще не крепится к аттачменту, а просто спавнится там, где был аттачмент, поэтому отстает, и при увеличенном времени это заметно. По-хорошему всю систему маззлфлешей вообще надо как-то переделать...но это уже другая история.
Aynekko писал: По-хорошему всю систему маззлфлешей вообще надо как-то переделать...но это уже другая история.
Дело вообще в темпэнтитях, а не только в маззлфлешах. Я подменил вызов вспышки вызовом искр. Проскакивать стало реже. А вот когда подменил вызовом короткого звука, услышал, что иногда тишина, а иногда эхо, звук двоит или троит. Короче, придётся крутить интервалы отлова эвентов и на клиенте тоже.
Отправлено Sigurth 31-03-2021 в 08:16:
Цитата:
Ku2zoff писал: Лучше вынести из движка в клиентку содержимое IEngineStudio.StudioClientEvents, и заменить вызов этой функции на свою, которая будет корректно работать.
Дело в том, что выносить нужно не только это. Я редактировал не одну функцию на сервере, чтобы все работало, как работает сейчас, очень долго боролся с правильным местом для m_fSequenceFinished, из-за чего у меня и не работали контроллеры. Попробовал свой костыль с мессагами. Ни один маззлфлеш не проскакивает, все отображаются, правда не знаю как правильно считывать аттачмент, либо рисуются в оригине модели, либо вообще где-то над дулом. Я так и быть, трогать клиентскую часть не буду, чтобы не наплодить багов. Сегодня- завтра ждите исходники серверной длл и мини-тутор с пояснениями, если еще баги не найдутся на сервере
Добавлено 31-03-2021 в 15:16:
Цитата:
Ku2zoff писал: Действительно, проблема только со спрайтами маззлфлешей. Клиентские елайты создаются
Нет, со спрайтами все ОК, а елайты создаются из-за pev->effects |= EF_MUZZLEFLASH; Проблема в клиентском отлове ивентов
__________________ Никогда не поздно сделать мод под хл1
Отправлено Дядя Миша 31-03-2021 в 08:58:
Цитата:
Sigurth писал: очень долго боролся с правильным местом для m_fSequenceFinished
Его установку в TRUE надо вообще выбросить из DispatchAnimEvents.
Добавлено 31-03-2021 в 11:58:
Цитата:
Sigurth писал: Проблема в клиентском отлове ивентов
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 31-03-2021 в 09:05:
Цитата:
Sigurth писал: Дело в том, что выносить нужно не только это.
Там, в общем-то, почти всё вынесено. Нету только StudioClientEvents.
Цитата:
Sigurth писал: боролся с правильным местом для m_fSequenceFinished
Это чисто серверная вещь для индикации, кончилась анимация, или нет. Ну я гадать не буду, сначала надо увидеть изменения на сервере, которые ты внёс.
Цитата:
Sigurth писал: елайты создаются из-за pev->effects |= EF_MUZZLEFLASH
Буду проверить. Подозреваю, что так и есть, но лишний раз убедиться не помешает.
Цитата:
Дядя Миша писал: на клиенте нет проблемы отлова событий
Если так, значит ноги у проблемы растут всё-таки с сервера. В любом случае, надо навтыкать алертов в StudioClientEvents и смотреть консоль.
Отправлено Дядя Миша 31-03-2021 в 09:30:
Возьмите циклер, поставьте его на карту и контролируйте проигрывание чисто клиентских событий. Будет вам такой юнит-тест.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Sigurth 31-03-2021 в 10:52:
Цитата:
Дядя Миша писал: Его установку в TRUE надо вообще выбросить из DispatchAnimEvents
Уже сделано, он у меня устанавливается только в StudioFrameAdvance. Но я там вообще порядок вызова этих функций поменял немного, короче все увидите чуть позже.
Цитата:
Дядя Миша писал: на клиенте нет проблемы отлова событий
Значит проблема не в отлове, а в том, что на клиенте сам кадр в ивентом просто проскакивает каким-то образом. Может, съедается интерполяцией (не кидайте тапками, если сморозил бред). Не знаю, я с клиентской частью моделей плохо дружу, просто предполагаю. Просто если сделать костыль с отловом клиентских ивентов на сервере и посыланием их мессагами в клиент, то все маззлфлеши рисуются без исключений, и рисуются в нужное время, и я бы так и оставил такой способ у себя, если бы смог правильно рассчитать позицию аттачмента.
__________________ Никогда не поздно сделать мод под хл1
Отправлено Дядя Миша 31-03-2021 в 14:54:
Секвенция меняется раньше, чем клиент её ловит.
Я ж говорю - на циклере проконтролируйте.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Crystallize 31-03-2021 в 16:18:
А проверьте ещё gruntbattledemo
Отправлено Ku2zoff 31-03-2021 в 16:34:
Цитата:
Sigurth писал: Значит проблема не в отлове, а в том, что на клиенте сам кадр в ивентом просто проскакивает каким-то образом.
Проигрывается только один раз. Допустим, грант стреляет из дробовика 8 раз. При первом выстреле эвент играется, при последующих нет, если серия не будет прервана другой анимацией - пинком или перезарядкой. Перестают ловиться нулевой и первый кадры на клиентской стороне. Если отредактировать модель - всё становится хорошо.
Добавлено 31-03-2021 в 23:34:
Хотя, может проиграться и два раза. В первые пару секунд после загрузки сейва, когда игра немножко "лагает". Наверное, чем выше фпс у анимации, тем больше будет пропущено кадров в её начале.
Отправлено Дядя Миша 31-03-2021 в 16:56:
Цитата:
Crystallize писал: А проверьте ещё gruntbattledemo
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Aynekko 31-03-2021 в 18:07:
Раз тут про ИИ идет разговор тоже, сейчас обнаружил у солдат одну штуку, которая сильно уберет у них тупняк. В Task_t tlGruntRangeAttack1B[] нужно закомментить
и таким образом они больше не стоят 2 секунды глядя на игрока, как баран на новые ворота, а начинают стрелять прям тут же. Если игрок за углом, то солдат начинает стрелять, только лишь показавшись из-за угла. Вот думаю пока, чтобы такое подсунуть туда вместо этого акта, чтобы ожидание было пол-секунды, а не две-три.
В атаке 1А стоит ACT_CROUCH - солдат сначала приседает. Ну тут ладно.
C++ Source Code:
{ TASK_WAIT, (float)0.1 },
хорошо срабатывает, почти то, что надо. Можно попробовать задрать фпс анимации combatidle еще. Пока она не проиграется, солдат стрелять не будет.
Aynekko Да, это ты правильно сделал. Я тоже эти строчки у себя убрал. Лучше и ACT_CROUCH тоже закомменти, у меня какая-то бесячая ситуация была в поведении грантов, и комментирование этой стройки ее исправило. Кажется, дело было в автоматной очереди. Да, вспомнил. У меня в моде гранты не используют звуки автоматной очереди. Вместо этого они используют три раза звук одиночной стрельбы. И иногда TASK_PLAY_SEQUENCE_FACE_ENEMY сбивал их очередь своей анимацией, что выглядело некрасиво. И было заметно по звукам. Короче, автоматные очереди иногда обрывались тупым стоянием или сидением
__________________ Никогда не поздно сделать мод под хл1
Отправлено Aynekko 31-03-2021 в 18:24:
Sigurth, тогда получается, что они у тебя вообще никогда не приседают?
Aynekko Приседают. Я раньше тоже думал, что эта активность нужна, чтобы перевести их в сидячее положение, но нет. Ведь самой анимации приседания у грантов нет. Есть только анимация стрельбы уже в приседе и анимация бездействия тоже в приседе. А визуальный присед происходит благодаря интерполяции.
__________________ Никогда не поздно сделать мод под хл1
Отправлено Дядя Миша 31-03-2021 в 18:35:
Цитата:
Aynekko писал: В Task_t tlGruntRangeAttack1B[] нужно закомментить
Какие-то тупняки весьма вероятно были введены самой вальвой, чтобы дать игрокам больше шансов, особенно трактористам.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 02-04-2021 в 14:46:
Дядя Миша авторы свенкоопа эти тупняки убрали. Так что в него вообще, в этот свен, играть невозможно из-за поднятого хп монстров до конских величин. Одно из двух - либо жырные, тупые и медленные монстры, как в ку2, либо шустрые и умные, но слабенькие.
Отправлено Дядя Миша 02-04-2021 в 15:10:
Самая идея, что один человек может завалить несколько сотен противников идёт вразрез с реальностью. Тут либо условность, как в дефматче, где просто начинается новый раунд. Либо сама игра не предполагает, что все друг-друга отстреливают. Ну взять тот же сталкер, там тебя если в коробочку зажмут, даже бронька не спасёт. Лучше лишний раз не нарываться.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 02-04-2021 в 15:24:
Цитата:
Дядя Миша писал: там тебя если в коробочку зажмут, даже бронька не спасёт.
Сталкер в этом плане хорош, я всегда кемперю и отстреливаю противников из укрытия. Есть у тамошних НПС одна поганая особенность: стоит игроку открыть PDA или инвентарь, они активно начинают пытаться зайти к нему с тыла. Стоит просто встать где-то на уровне и ничего не делать, они будут топтаться туда-сюда, но не выходить на линию прямой видимости. В этом случае очень помогает встать в угол спиной, и тогда можно хоть полчаса копаться в инвентаре или пда.
Добавлено 02-04-2021 в 22:24:
Где-то я читал, что в сталкере прям специально написан такой код, что НПС пытаются обойти игрока, и зайти с тыла. В общем, это логично. Но вот то, что это чаще происходит при открытом инвентаре, капец как накаляет.
хотелось бы видеть тутор по фиксу AI - это очень бы пригодилось всем.
Это же не стандартная переменная. 
