akortunov

1. Сейчас @# в OpenMW вообще не используются - темы генерируются автоматически, как в английской версии. 2. Что дает подход с сохранением вариантов ссылок прямо в тексте по сравнению с TOP-файлами, ну, кроме проблем с обратной совместимостью?

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

Насколько я помню, в StormRider'е проблема как раз с физикой - телепортационные команды в Морровинде задействуют физику для обнаружения коллизий (мы не знаем, как именно), а OpenMW честно перемещает объект в заданную позицию. Например, скрипт перемещает лодку на 10 единиц через SetPos каждый кадр, но если позиция реально изменилась на меньшее число, то лодка с чем-то столкнулась. В OpenMW такой подход не работает, да и в оригинале он глючит.

Но если сделать новое оружие низкополигональным, а игрок использует высокополигональные реплейсеры в оригинальном стиле для остального оружия (а в 2018-м году это не редкость), то это совсем не хорошо. Да серьезно, если реалистичный реплейсер довести до ума и выложить в массовый доступ, то первым делом будут просить сделать модели высокого качества. Я читал, что такие мечи изготавливались в качестве подарков лордам или подношений в храмы. Мотивация типа "я выковал Самый Большой В Мире Меч". Самые большие боевые образцы были около 120-140 см. длиной и использовались в основном против кавалерии. Дурой же длиной 220 см. разве что вдвоем махать.

А для кого я распинался выше, когда расписывал, как анимации перезарядки арбалетов работают? Анимация одна, она же "shoot follow". Просто она задействует все тело целиком, но при перемещении персонажа анимации движения перекрывают анимацию перезарядки для нижней части туловища, вот и перезаряжают персонажи арбалеты на ходу. Причем если во время перезарядки персонаж начинает или прекращает двигаться, переключение между стойками идет мгновенно. В результате к 0.45 пока было принято решение применять анимацию перезарядки арбалета только для верхнего туловища (т.е. анимация всегда как "в движении"), т.е. твой баг в 0.45 проявляться не должен. Соберем фидбэк от пользователей и решим, что делать дальше. Capostrophic тут напустил туману. Если вкратце: 1. Надо таки доделать тени. 2. Довести до ума навмеши, что позволит закрыть львиную долю претензий к ИИ. 3. Довести до ума боевые анимации. 4. Реализовать несколько мелких фич (перезаряжать магические предметы вне инвентаря героя, позволить ряду консольных команд менять базовые записи и т.д.) 5. Довести до ума физику. 6. Решить ряд проблем с производительностью. 7. Долго и нудно ловить мелкие баги в модах, т.к. в 1.0 заявлена совместимость с ванильными модами. Причем приличное количество модов используют неочевидные, недокументированные или откровенно глючные решения, которые вообще непонятно, как воспроизводить. Скорее всего, п.п. 1-4 примерно к 0.46 закроют, п.п. 5-6 у нас пока особо реализовать некому, п. 7 будет реализоваться параллельно остальным. Редактор я не учитываю, т.к. Zini уже говорил, что если движок будет готов, а редактор - нет, то 1.0 будет без редактора. А вообще, если глянуть в ретроспективе, версия 0.43 была про distant terrain, ИИ и интерфейс, 0.44 больше про совместимость с модами, а в 0.45 много фиксов анимаций.

Он сам уже признался, что позабыл детали. К тому же я спрашивал про костыли, глюки и другие забавные особенности оригинального движка. Я могу посоветовать только багрепорт создать, желательно с приложенной модифицированной моделью и видео (или хотя бы с моделью). Может, кто-нибудь сумеет помочь. Мои же познания в анимациях базовые.

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

На ходу, в прыжке и при плавании персонажи взводят арбалеты одной рукой. Спасибо тебе, смешение анимаций.

Которые являются церемониальным и коллекционным оружием, а не боевым. А вообще "дайкатана" (которая на самом деле дайто) - это же вроде расхожий термин для обозначения японских мечей длиной 60 см и более? В этом случае одно другому не мешает. А так да, у дайкатан в Моррке длина вроде около 150 см. Укоротить все это добро не помешало бы. Только одна просьба с "реалистичными моделями" - сделайте версию для высокополигональных моделей (топоры с шестигранными лезвиями, на которые натянута текстура от круглого лезвия, в 2018 году смотрятся глупо). Отдельное замечание по темам в диалогах: там присутствуют замечания типа ранжирования оружия по эффективности. С твоим ребалансом эти замечания могут стать нерелевантны. Также переименовать дайкаданы в нодати относительно несложно (один черт записи оружия все править, но там надо тоже будет пару диалогов поправить.

Ну так боевые арбалеты и были примерно 80-100 см в длину (на снимке, что приводил я, длина около метра). Так как арбалеты в Морре перезаряжаются руками, брать можно нижнюю границу. Или же брать за основу не боевой, а охотничий арбалет.

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

А мне больше вариант с деревянным луком нравится. Оставить стальной только центральную часть. По поводу "раздутия" арбалетов: 1. Увеличивать лук в ширину можно относительно спокойно, анимации поехать не должны 2. Если будешь удлиннять ложе, удлинняй только в сторону приклада (там есть немного места до руки) - персонаж должен упереть ногу в стремя при перезарядке. 3. Персонажи и так держат арбалеты криво, так что особо хуже вряд ли сделаешь. По размеру бы что-нибудь примерно такое получить (фото из музея), или чуть поменьше (т.к. арбалеты в Моррке натягиваются руками):

ИЧСХ, у меня у этих стрекоз анимация тоже проигрывалась один раз в Морровинде. Ставил я этот мод несколько лет назад. Насколько я помню, эти же стрекозы в Better Sounds используются, да?

Насколько я помню, оно сейчас в OpenMW так и работает. Другое дело, что скрипт, использующий эту фишку, будет вылетать в Моррке. С изменением навыков такая фишка тоже не прокатит. Видимо, жалко. Необходимости править поля базовых записей изначально не было, вот их тупо и читают из основной ESM-записи. В игре могут быть тысячи экземпляров существ. Лишние поля - это дополнительное время загрузки сохранения и сохранения бОльшего размера (которые и так довольно распухшие).

Не знаю как в Морре, но в OpenMW навыки существ хранятся в базовой записи, которая в ESM-файле хранится - одними консольными командами здесь не обойтись. Надо эти навыки для экземпляров существ уметь отдельно хранить, читать и менять. Также в MWScript никто новые команды добавлять особо не собирается, ни до 1.0, ни после.

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

Не вижу никакой разницы. Что в 0.43 анимации атаки баговатые, что в 0.44, что в мастер-ветке. Багрепорт вон с 2016 года висит.

https://gitlab.com/OpenMW/openmw/issues/3330 https://gitlab.com/OpenMW/openmw/issues/4127 С анимациями атак полно проблем. К сожалению, отлаживать их очень сложно. Как я понял, у анимаций атаки прописано небольшое движение, причем если анимация проиграна полностью, то результирующее движение будет ноль. Но похоже, что мы не проигрываем их правильно (так какая-то ерунда с замахом), вот смещение и остается..

Пришли. Сошлись на том, что достоинства перевешивают недостатки: 1. TES3MP и MWSE2 используют Lua, так что модерам надо будет только один язык учить. 2. Lua - один из самых быстрых скриптовых языков, и специально предназначен для встраивания в другие программы (для него проще сделать песочницу) 3. Lua довольно популярен и частенько используется именно для скриптования игр, и модеру будет легче найти примеры. Из недостатков приводят в основном то, что он не особо эстетичен, как что периодически всплывают комментарии "а сделайте лучше JavaScript/Rust/AngelScript". Также отдельный вопрос с автоматизацией редактора - там вроде в планах Python есть (непонятно, зачем). А момент выхода из канцелярии разве движком ловится, а не скриптами? Разве что скриптовую команду для автосейва добавить.

Уже поднималась эта тема. Перетряхивать игровую механику на уровне движка сейчас бессмысленно: 1. До 1.0 никто это мержить не будет, т.к. OpenMW должен воспроизводить оригинальную механику по умолчанию. Добавлять опции на каждый чих - тоже гиблое дело. 2. После 1.0 проще перенести механику в LUA-скрипты и все правки делать в виде модов, а не в виде своего форка движка. Особенно это касается текущей морровиндовской боевки, по поводу которой у всех куча предложений, как ее переделать. Короче, можно начинать капать на мозг NullCascade, чтобы он потихоньку реализовал фишки MWSE2 для OpenMW. Если же есть желание пропатчить OpenMW, то лучше заняться ИИ, интерфейсом и редактором (особенно редактором).

Да, сверху должны быть Tribunal и Bloodmoon. Порядок загрузки файлов можно в openmw.cfg посмотреть (~/.config/openmw/openmw.cfg). Должно быть что-то такое: content=Morrowind.esm content=Tribunal.esm content=Bloodmoon.esm [остальные плагины] Автосгенерированный список сортируется по дате изменения файлов, но при копировании файлов с другого компьютера Linux считает дату создания файла на диске датой его изменения. Т.е. в каком порядке файлы переносились/распаковывались, в таком они в списке и будут, и ничего удивительного в том, что Bloodmoon в середине списка.

Вам лучше в тему OpenMW перейти или на багтрекер. Проблема может быть в том, что у вас там несколько файлов стальных кирас (например, из-за объединения разных модов), которые отличаются только регистром. Поскольку внутренняя файловая система OpenMW регистронезависимая, какую из них игра в этом случае возьмет - черт его знает. В крайних версиях (вроде в 0.44) в этом случае выводится предупреждение в лог. Если файл только один (плюс второй - оригинальный - внутри Morrowind.bsa), то это однозначно баг в OpenMW.

UPD: похоже, ты прав, это я туплю (там аж два раза узел обернут). На стороне движка-то что делать? Как вариант, можно попробовать не считать корневыми при вычислении коллизий узлы NiNode, у которых есть только один дочерний узел - другой NiNode. DN_H_fan.nif

Если так, то это грустно - "горе-моделлеры" - это Abot, Darknut, SureAI, разработчики Morrowind Rebirth и еще куча народа. А вообще, стОит ли такие узлы обрабатывать, учитывая, что они в куче модов используются, или достаточно предупреждение выводить о косячности модели?

Да все бы ничего, если бы не этот баг. Люди жалуются, что если RootCollisionNode не к корню прикреплен, OpenMW целиком меш для коллизии использует, причем включая собственно RootCollisionNode, что создает дополнительную нагрузку на физику. Morrowind это как-то обходит. Вот я и спрашиваю, как оно точно работает. ИЧСХ, до фига модов прикрепляют такие узлы не к корню, значит, оно зачем-то надо?