PLut солидарен с тобой в том, что текстовых меню вполне достаточно. Но я бы завёл квар, который бы переключал стандартные ВГУИ-менюшки в минималистический режим. То есть панели невидимые, картинок нет, циферок нет, меню поменьше, чем полноформатное, но не такое маленькое, как обычное текстовое. Ну и мышка не перехватывается ВГУИ-вьюпортом, только клавиши. Так было бы очень удобно. Новички могли бы рассматривать картинки в меню и читать описания, а профи не мучались бы от мелькания панелей перед глазами. И да, минималистичное ВГУИ можно раскрашивать, добавлять туда маленькие иконки, звуки и проч.
PLut писал: И вот скажи, часто ты любовался в магазине кс на картинки оружия и их характеристики, которые к игре не имеют ни малейшего отношения?
Для новичков это необходимо. В качестве ознакомления с оружием. Я в ХЛВЕ делал описание. Оно более информативное было, имхо. Ну чем в каэсе, да.
Добавлено 18-09-2015 в 22:43:
Цитата:
Ku2zoff писал: Но я бы завёл квар, который бы переключал стандартные ВГУИ-менюшки в минималистический режим. То есть панели невидимые, картинок нет, циферок нет, меню поменьше, чем полноформатное, но не такое маленькое, как обычное текстовое.
полностью согласен.
__________________
Ты топчешь мир своими ботинками,
Не замечая куда наступаешь,
А время от тебя уходит цветными картинками,
Но ты даже этого не понимаешь.
Компрометирую данные своей учётной записи.
ЛОГИН: Ghoul [BB]
ПАРОЛЬ: paladin_solo
А вы видели описание в OI:FD?
Там оно имеет реальное отношение к игре - т.к. характеристики в игре учитывались. Ну и плюс небольшая справка для интересующихся.
Так. Товарищи. Есть вопросы к вам. Хочу услышать ваше видение. Как себя должны вести монстры в бою? Вопрос такой возник потому, что мало научить их просто стрелять не останавливаясь. Нужно ещё написать новые таски для AI, чтобы движение в бою использовалось с максимальной эффективностью. Что от вас требуется:
1. Пишем имя монстра, например, monster_human_grunt.
2. Пишем, нужно ли ему двигаться и одновременно выполнять какие-то действия (которые уже есть в оригинальной халфе), завязанные на анимациях, что на данный момент в халфе невозможно. (Если сюда пишете нет, то пункт 3 пропускаете, можно сразу перейти к п.4. Если да, то, соответственно катаете п.3).
3. Действия расписываем (а, б, в и т.д.), описываем ситуации применения.
4. Предлагаем какие-нибудь комбинации/последовательности действий, которых нету в оригинальной халфе. Можно предложить новые способы передвижения - перекат/стрейф/прыжок (при условии, что в стандартной модели есть нужные анимации. Для стрейфов, наверное не нужно, т.к. в обозримом будущем я попытаюсь прикрутить бонеконтроллеры).
5. Ещё какие-нибудь ваши соображения/мечты. В пределах разумного.
Если мнение по монстру уже кем-то оставлено, то в пункте 2 вы можете написать нет (если по вашему мнению монстра надо оставить таким, какой он есть, или наоборот - да). В пункте 3 пишете только отличия, используя буквенную нумерацию предыдущего оратора. То же самое с п.4. В п.3. и п.4. можете написать "не нужно", если мнение, оставленное до вас, вам кажется неуместным. Желательно аргументировать. Пункт 5 пишите как хотите.
К чему всё это? Я совсем не уверен, что мне хватит фантазии использовать все возможности модифицированного AI. Надеюсь на мапперов, которым чего-то не хватает в халфе. Ну и чуть меньше на игроков. Давайте пожалуйста не будем флудить или даже по теме писать, но не в формате, что я предложил, пока не наберётся хотя бы 10 мнений. Мне просто лень выглядывать нужные посты среди других Я знаю, что эта тема относительно популярна, и надеюсь, что трёх-четырёх дней хватит.
Что получается: монстра вполне реально заставить двигаться задом наперёд, чтобы он, отступая от врага, смотрел на врага. Но всё дело портит меркзая функция CBaseMonster::ChangeYaw, которая много где вызывается, и поворачивает монстра в направлении движения. На данный момент я использую хак, при котором вместо направления движения указывается направление на врага. Но хак невероятно грязный, прям до ужаса:
C++ Source Code:
if (m_pSchedule && !_stricmp(m_pSchedule->pName, "Retreat") && m_hEnemy)
То есть из обязательных условий здесь скедъюл с названием Retreat. Как бы придумать другое условие? Чтобы отвязаться от конкретного имени? Чтобы определять скедъюл как-то по-другому? Условие нужно только для каких-то конкретных скедъюлей, которых может быть у разных монстров куча, соответственно и имена у них разные. Трогать структуру Schedule_t не хочу. Кто поможет? Может быть добавить в iInterruptMask какой-нибудь особый флаг? Не так болезненно, как изменять структуру?
А может быть вообще какой-нибудь более изящный способ есть?
Что, никто в монстрах не шарит что ли? Это несерьёзно, товарищи.
Работа не стоит на месте. Подглядел методом псевдонаучного тыка, где в свенкоопе клиентский код студиомодельрендерера хранит gaitframe монстра: в m_pCurrentEntity->curstate.iuser1. Я-то думал, что в fuser1. Там как раз в delta.lst новые строчки в EntityEncode есть:
C++ Source Code:
//Sniper
DEFINE_DELTA( fuser1, DT_FLOAT, 8, 1.0 ),
DEFINE_DELTA( fuser2, DT_FLOAT, 8, 1.0 ),
DEFINE_DELTA( iuser1, DT_INTEGER, 8, 1.0 ),
DEFINE_DELTA( gaitsequence, DT_INTEGER, 8, 1.0 ) //Monsters can have gaitsequences now.
Ясно для чего юзают gaitsequence. Думал, что fuser1 юзают для gaitframe. Думал, что fuser2 для какого-нибудь float'a, в котором хранится время с момента смены предыдущего gaitsequence на текущий, для замутки интерполяции. Про iuser1 вообще ничего не думал. Теперь, раз точно известно, что iuser1 это gaitframe:
то думаю, что один из fuser'ов отвечает за время, а второй за gaitmovement. Хотя не уверен, нужен ли монстрам в свенкоопе gaitmovement. Я немного поиграл, но не видел, чтобы какие-нибудь монстры пятились. Именно для этого и нужен gaitmovement, чтобы считая его определять, в какую сторону анимировать gaitsequence. Чтобы не было "лунной походки", про которую писал PLut. Ещё помнится PLut раскритиковал мою первую реализацию, опробованную на алиен_грантах за дёрганность движения. У агрантов анимации бега сами по себе дёрганные, тут ничего не поделаешь. А я ещё не сделал интерполяцию. Посмотрел в свенкоопе с низким значением host_framerate - тоже дёрганно, но интерполяция между gaitsequence есть. Буду пилить.
Ku2zoff Ну анимация у агрантов - это одно, я вот именно про интерполяцию говорил. Так что вот запилишь, должно круто получиться
Похвально, что не бросаешь!
Замутил интерполяцию. Вроде работает. Но говнокод ещё тот С другой стороны, я не представляю, где хранить время переключения и гейтсеквенцию с предыдущего энтити стейта, а так же гейтфрейм (одинаковый для обоих стейтов). Хранить негде, кроме как в энтварсах. Волшебная структурка под названием latchedvars_t не включает в себя каких-то дополнительных полей, да и трогать её я бы не стал. Вдруг интерполяция между обычными секвенциями изломается?
Чуть позже выложу вам два видео, с интерполяцией и без. Чтобы было видно разницу.
Добавлено 25-09-2015 в 21:42:
Добавлено 25-09-2015 в 21:46:
А вот то же самое, только в одном видео:
Добавлено 25-09-2015 в 21:50:
Ну што?
Добавлено 25-09-2015 в 22:12:
Вот минимод. Та самая демка, с которой писал видео, внутри. http://rghost.ru/6qY6N4W9p
Можете поиграться с кваром studio_lerp_gait, и поглядеть разницу сами. Гейтсеквенции сделаны только для барника. Скедъюлы не написаны, поэтому поведение у него абсолютно обычное, только нижняя половина анимируется гейтсеквенцией.
Добавлено 25-09-2015 в 22:18:
PLut, если у тебя остался код алиен_грантов, который я тебе когда-то давал (я не помню уже, но вроде давал что-то), то можно попробовать влепить интерполяцию на клиент. Посмотришь, как оно будет. Заодно со скоростью передвижения в том старом коде ещё разберёмся.
Добавлено 25-09-2015 в 22:26:
З.Ы. Демка должна работать на вон-халфе, т.к. собрана из подправленных под 2013 студию сорцев, которые XaeroX выкладывал для 2005 студии.