akortunov

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

Если что, здесь имеется в виду AiFollow. В Морровинде последователь начинает поворачиваться к лидеру, если угол между ними больше 45 градусов. В OpenMW они же поворачивались строго к лидеру каждый кадр вне зависимости от угла. В ситуации, когда непись следует за другим неписем, это вело к дерганой анимации у последователя.

Чем я и планирую заняться в ближайшем будущем. Ну, в общих-то чертах понятно. Пока что я не понимаю, почему опции сгруппированы по четыре штуки. Чем Pre и Post отличаются? Например, солнце: Sun Pre-Sunrise Time=0 Sun Post-Sunrise Time=0 Sun Pre-Sunset Time=1 Sun Post-Sunset Time=1.25 Так когда фактически зайдет солнце с такими настройками: Sunrise Time=6 Sunset Time=18 Sunrise Duration=2 Sunset Duration=2

Может кто-нибудь подсказать, за что в Морровинде отвечают эти настройки: Sky Pre-Sunrise Time=.5 Sky Post-Sunrise Time=1 Sky Pre-Sunset Time=1.5 Sky Post-Sunset Time=.5 Ambient Pre-Sunrise Time=.5 Ambient Post-Sunrise Time=2 Ambient Pre-Sunset Time=1 Ambient Post-Sunset Time=1.25 Fog Pre-Sunrise Time=.5 Fog Post-Sunrise Time=1 Fog Pre-Sunset Time=2 Fog Post-Sunset Time=1 Sun Pre-Sunrise Time=0 Sun Post-Sunrise Time=0 Sun Pre-Sunset Time=1 Sun Post-Sunset Time=1.25 Stars Post-Sunset Start=1 Stars Pre-Sunrise Finish=2 Из них только "Sun Pre-Sunset Time" используется в OpenMW. Есть также старый багрепорт: https://bugs.openmw.org/issues/1990 Здесь пользователь жалуется, что поведение закатов и рассветов в OpenMW отличается от такового в Морровинде.

Немного новостей: scrawl решил провести генеральную уборку на Гитхабе. Часть pull request'ов была закрыта, часть принята (даже те, которые висели по несколько месяцев). Среди включенных в основную ветку много моих наработок. Вот они: 1. Новый пакет ИИ AiBreathe, который позволяет неписям всплывать подышать свежим воздухом, вместо того, чтобы глупо тонуть. 2. Учет сопротивления противника нормальному оружию при выборе оружия ИИ. 3. Улучшения меню покупки заклинаний: заклинания отсортированы по имени, а также не нужно отматывать весь список сначала после каждой покупки. 4. Кнопки "ОК/Отмена" в виджете выбора предметов из пачки выравнены по центру. 5. При расчете приоритета заклинания у ИИ учитывается дальность (+50% для заклинаний "Удаленная цель") и область поражения. Также приоритет заклинания нормирован к приоритету оружия - до этого любое заклинание имело приоритет в 10-50 раз выше, чем даже очень хорошее оружие. 6. Лучники теперь не будут пытаться подстрелить цель, находящуюся в воде. И не будут пытаться стрелять из воды на сушу, т.к. все равно сработает коллизия стрелы с водой. 7. Улучшено открывании дверей неписями: теперь ИИ может открывать двери в любых ячейках (раньше работало только в интерьерах), добавлена проверка, что NPC стоит лицом к двери. 8. Перелистывание страниц дневника теперь озвучено. Также отдельно могу выделить фикс idle-анимаций, который залил Allofich. Теперь музыканты в Animated Morrowind будут корректно анимированы. Определение полного же списка всех изменений может занять много времени. P.S. Если текущая пачка изменений включена в основную ветку, то что? Правильно, можно отправлять следующую.

Обратная совместимость. По-какой то причине программисты Бетесды выделили 32 бита для хранения цены всех объектов, кроме одежды (там 16 бит). Наверное, посчитали, что дорогой одежды не бывает. В ESM и ESP файлах та же ерунда. OpenMW использует обычный int для хранения цен, для цен одежды - short (был изменен на unsigned short). Я пытался там тоже поставить int, но получил вылет при чтении данных с Morrowind.esm.

В Морровинде - вроде вариант б). Сначала неписи используют бижутерию (даже если она очень слабая), затем переходят на обычные заклинания. Причем ухитряются использовать даже предметы из рюкзака - рубашки, ботинки и т.д. Скорее всего, потом будет опция-переключатель между стандартной боевой логикой (включена по умолчанию) и расширенной. В стандартной логике постараюсь сделать ближе к тому, что было в оригинале, в расширенной - как оно должно работать? Сейчас у меня идет расчет приоритета по той же формуле, что и для заклинаний - по эффективности (с учетом силы заклинания, длительности, сопротивлений и т.д). Плюс проверка, что предмет экипирован. Т.е. у меня сейчас разницы между зачарованиями и заклинаниями нет. Дефолтное правило "сначала все предметы, а затем заклинания" вставлять не хочу - ИИ будет тратить время на копеечные бирюльки. Может, там просто множитель какой добавить? Также - должен ли ИИ экономить заряды? Например: если лучшее действие непися - это использовать кольцо огненных шаров, то должен ли он выпалить все заряды сразу, или по мере расходования зарядов его должна начать душить жаба (приоритет кольца снизится)?

По поводу стрельбы на упреждение: она в OpenMW реализована только для оружия дальнего боя, не для заклинаний. Создал запрос: https://bugs.openmw.org/issues/3948 Еще вопрос: как NPC в Морровинде используют предметы с зачарованием "При использовании"? По моим наблюдениям, кривовато: 1) Используются только негативные эффекты (т.е. никаких тебе щитов Велоти или колец жизни) 2) Каждый тип предмета используется только один раз, т.е. если у персонажа есть 10 одинаковых колец огненных шаров, он использует только одно и один раз. Наверное, пока оно полностью не перезарядится. 3) Нет проверки на то, что используемый предмет экипирован. По крайней мере, для рубашек и колец. Предлагаю использовать такие предметы в OpenMW как обычные заклинания, только добавить проверку на то, что предмет экипирован.

Сейчас ИИ в основной ветке OpenMW вообще не замечает разницы между заклинаниями, бьющими единичную цель, и заклинаниями, бьющими по площади. Как я понял, ИИ кастует в точку местонахождения противника на момент завершения каста. Это не упреждение, так что я ошибся. Но идея кидать заклинания типа огненного шара в пол возле цели интересная, т.к. в текущей реализации в случае промаха заклинание тупо будет лететь до ближайшего препятствия. Кстати, а как Morrowind ведет движущиеся цели? Насколько я помню, там тоже можно было легко уклониться.

Поддерживаю. А вообще после 1.0 для таких моментов можно вообще скриптовую функцию вызывать, в которой хоть погоду на Марсе можно учитывать, и изменение исходного кода не нужно. Подобная система, например, в "Звездных Волках" работает. Кстати, хорошая мысль. Благодарю, наверное, так в итоге и сделаю. Конкретно по поводу ударов по площади: склоняюсь ко второму варианту как к более простому и реалистичному. Все равно в свалке "свои против чужих" непонятно, кому в результате прилетит на орехи. Разве что его можно немного расширить: не учитывать в качестве вторичных цели, иммунные к эффекту. Чтобы если вдруг в ситуации типа вместо скампа оказался Огненный Атронах или Данмер с Огненным щитом, то можно было жарить вражин без проблем.

В текущей реализации - тех, на кого у колдующего нет пакета AiCombat. По идее, такой пакет есть на каждого противника в зоне видимости.

Товарищи, нужен ваш совет. Как известно, в OpenMW боевой ИИ не проверяет, что в области действия заклинания (типа Огненный шар или Искра) есть дружественные существа. Это легко проверить в Гильдии Магов Балморы: атакуйте кого-нибудь, и Гальбедир умножит на ноль все население локации с помощью свитков. В Морровинде подобная проблема тоже есть. Соответственно, вопрос: как разруливать подобные ситуации? Интересует логика, без технических подробностей. Сейчас боевая логика в OpenMW очень простая: 1) Выбираем ближайшую цель 2) Оцениваем все возможные действия применительно к этой цели 3) Выполняем действие с наивысшей оценкой Причем учитывается только влияние на выбранную цель. Более-менее рабочий вариант оценки заклинания, бьющего по площади: 1) Получаем список существ в области действия (центр - выбранная цель). 2) Пробегаемся по списку: если существо враждебное, увеличиваем оценку, если дружественное - уменьшаем (с учетом сопротивления против эффекта, естественно). Т.е. ИИ будет бить, если предполагаемый сопутствующий ущерб будет меньше предполагаемого ущерба противнику. Проблема в том, что между принятием решения и его реализацией может пройти несколько секунд (особенно если у заклинания радиус действия - касание). За это время многое может произойти - кто-то выйдет из зоны поражения, кто-то войдет и т.д. Соответственно, довольно сложно определить заранее, кто будет в зоне поражения, когда заклинание попадет в цель. Альтернативный вариант в этом случае: если в каком-то радиусе от цели (например, в два раза больше зоны поражения) есть свои, то не применять заклинание. Вариант намного проще первого, но лучше ли? Т.е. ИИ тупо не будет бить по площадям в свалке, когда можно задеть своих. Есть ли какие-нибудь идеи, предложения?

Если по-человечески: 1) У персонажей в OpenMW есть ссылка на локацию, в которой они находятся. 2) Если при выборе расы, пола, головы и прически оставить значения по умолчанию, то для персонажа игрока она не задавалась (считалось, что виджет ничего не поменял и ничего рассчитывать не нужно). 3) Если персонаж что-то говорит (например, стон при ударе), идет проверка - если персонаж под водой, то звук надо исказить. 4) Так как при этой проверке задействована локация (уровень воды в ней), а ссылка на нее не задана, игра вылетала.

Здесь имеется в виду то, что перед ответами нужно добавлять пустую строку, а перед приветствиями - нет (например, если вызвана команда ForceGreeting).

Да физику надо в отдельный поток выносить, желательно в несколько (тяжеловат все-таки Bullet). Это из-за нее FPS проседает в локациях с кучей объектов, например, в больших городах в Tamriel Rebuild.

Товарищи, кто-нибудь может мне помочь с форматом NIF? Конкретно интересует, как работает свойство NiVertexColorProperty->Lighting Mode Сейчас в OpenMW оно не обрабатывается, поэтому окна в Windows Glow не светятся как положено. Собственно, багрепорт: https://bugs.openmw.org/issues/3833 Хочу попытаться реализовать это свойство.

Пара скриншотов, чтобы было понятно, что это такое: 1. Параметр Chop у стрел и болтов: http://i.imgur.com/t1JhnIT.png 2. Параметры Reach и Speed у оружия ближнего боя (1.0 = 100%) http://i.imgur.com/nbdwN28.png Это уже в основной ветке и будет в релизе 0.43. P.S. Скриншоты сделаны на сборке с набором плагинов, на чистой игре характеристики будут отличаться.

А еще Arx Fatalis и Arcanum как минимум.

Сравнил поведение в оригинальной игре и OpenMW. Действительно, в Morrowind зависимость прямая, а в OpenMW - обратная. Я создал багрепорт, и если его не отклонят, то починю формулу.

Небольшой обзор "неванильных" изменений, которые могут со временем могут попасть в OpenMW; 1. Доработанные виджеты ремонта и перезарядки: http://i.imgur.com/1pPBNeW.png http://i.imgur.com/lZBrzs1.png http://i.imgur.com/4Tng7cP.png Позволяют переключение между инструментами/камнями душ без перезапуска диалога. http://i.imgur.com/YX8lTFS.png http://i.imgur.com/ujoUWlu.png Правда, поскольку камни с душами не формируют пачки, каждый камень душ пока надо выбирать отдельно - но это все равно быстрее, чем перетаскивать каждый камень на куклу персонажа. 2. Отображение шанса на успех при самостоятельном зачаровании: http://i.imgur.com/gUzGrRu.png

Исправление ванильных багов - понятие довольно противоречивое. После исправления может выясниться, что: 1) Исправление бага ломает что-то в чистой игре из-за багов в ресурсах (как в случае с мертвым Дагот Уром). 2) Исправление бага ломает некоторые моды, которые на этот баг опирались. 3) Есть игроки, которые воспринимают баги и эксплоиты как неотъемлемую часть геймплея и просят вернуть как было. Поэтому иногда приходится делать отдельную настройку под фикс. Аналогичным образом действует MCP - там под каждый фикс отдельный чекбокс. Только такой подход ведет к огромному конфигу с кучей настроек, что не нравится некоторым разработчикам, например, scrawl'у. Соответственно, общая идея такова: если фикс вроде бы никому не мешает (см. список из трех пунктов), то его могут принять, если мешает - то скорее всего будет костыль для совместимости или отдельная настройка (если фикс достаточно полезен). Под мой фикс с зачарованием скорее всего тоже будет отдельная настройка.

Если вы про этот раздел: https://wiki.openmw....Research:Combat то там описаны формулы из ванильной игры. Там fBlockStillBonus действительно не используется. Другое дело, почему его тогда использует OpenMW. По поводу усталости - интересная информация, я проверю. Благодарю за подсказку.

Можно получить ссылку на используемую вами формулу расчета высоты прыжка? Возможно, Morrowind делит высоту на encumbranceTerm, а не умножает, как OpenMW. OpenMW считает высоту прыжка как: encumbranceTerm = fJumpEncumbranceBase + fJumpEncumbranceMultiplier * (1 - currentWeight/maxWeight); height = height * encumbranceTerm; Нагрузка уменьшает высоту прыжка (как и в оригинальной игре). Если оставить только currentWeight/maxWeight, то нагрузка будет увеличивать высоту прыжка. По поводу блока: OpenMW точно применяет fBlockStillBonus, но я не уверен, применяет ли это значение Morrowind.