akortunov

Уже неоднократно тема поднималась. В принципе, это возможно, но тут надо прилично кода переписать, кучу анимаций отзеркалить (про анимации от первого лица тоже забывать не надо), изменить положение лука и колчана на спине, плюс делать все это как опцию. scrawl это дело стопудово не примет.Хотя, если кому-то совсем нечем заняться, и он сделает анимации, то можно попробовать. Также непонятно, где должна находиться прикрепленная стрела. Судя по коду, ее положение берется из модели оружия. Это значит, что зеркалить придется и луки, включая реплейсерные, иначе получится что-то такое: Что-то больно много изменений получается для небольшой чисто визуальной фичи.

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

Пожалуйста, если не сложно. Я один раз темы перепутал, и понеслась. Я отключал влияние запаса сил на торговлю и поставил ограничение торговцам на цену покупки в 75% от реальной цены.

Готов концепт подсумка с болтами на поясе. Ссылка на модель для стального арбалета: https://yadi.sk/d/N05LRXBA3Tm6Tw Для крепления подсумка используется кость "Bip01 Bolt".

Да, примерно так. Тогда у нас будет достаточно ресурсов для демонстрации фичи, что увеличит шансы того, что ее включат в основной код.Под экипированным оружием здесь имеется в виду лук или арбалет, т.к. колчан сделан по аналогии с ножнами. P.S. При текущей модели колчана лук на спине должен висеть в другую сторону, а не как сейчас.

Вот что получилось с колчанами (спасибо, CemKey!):

Значит, его и попытаюсь реализовать. Прикреплять разные стрелы к пустому колчану уже умею.Видимо, я где-то накосячил при редактировании модели, и положение колчана изменилось: Текущий статус: 1. Тип отображаемых стрел зависит от типа экипированных стрел. Если стрелы зачарованные, то они будут светиться. 2. Количество отображаемых стрел зависит от количества экипированных стрел и количества слотов в модели колчана (до 10 шт.). Количество отображаемых стрел уменьшается на 1, когда персонаж берет стрелу в руку. 3. Модель колчана должна иметь имя модели лука с суффиксом _quiver, в ней может быть до 10 пустых узлов с именами Arrow0-9, к которым будут прикрепляться стрелы. 4. Пока непонятно, что делать с арбалетами - они используют другой подход: судя по анимациям, персонажи достают болты не из колчана, а из подсумка на поясе. Здесь у нас два варианта: а) Добавить новую кость для подсумка, но подсумок на поясе может конфликтовать с некоторыми видами брони или мантий. б) Изменить анимации перезарядки арбалета, но на спине будет висеть коротенький огрызок - болты в игре в разы короче стрел. Код доступен здесь: https://github.com/a...eapon_sheathing Тестовая модель колчана для хитинового лука: https://yadi.sk/d/1zv6jp6c3Tj4aV

Возвращаясь к вопросу с колчанами, как их лучше сделать? 1. Их можно привязывать к модели стрел, как в поздних играх. 2. Их можно сделать частью самого лука, что-то типа ножен, а стрелы в колчане рисовать разными в зависимости от экипированного типа стрел. 3. Теоретически можно сделать колчан вообще отдельной деталью экипировки, но здесь слишком много работы без особой пользы. Отдельный вопрос - отображать ли колчан всегда или только когда экипирован лук. Во втором случае мы избавляемся от головной боли с подгоном позиции колчана под все типы оружия на спине + случай, когда оружия на спине нет. И в любом случае надо менять анимацию вытаскивания стрелы из колчана.

ПОЛНОСТЬЮ (т.е. всем диском) ниже горизонта солнце вообще не бывает - после заката оно становится прозрачным и двигается с запада на восток. На восходе оно начинает терять прозрачность и двигаться с востока на запад. Да, стремно. Чтобы это изменить, надо пересматривать механику движения небесных тел в игре, и тут можно что-нибудь поломать. Можно создать feature request, но далеко не факт, что кто-то им займется в ближайшем будущем. UPDATE: Переработал закаты и восходы. Теперь солнце реально заходит и выходит, но надо поиграть с параметрами Weather_Sun_Pre-Sunrise_Time и Weather_Sun_Post-Sunset_Time. Также я не уверен, что это будет работать с реплейсерами текстур солнца. Не получится, т.к. солнце отображается под водой - оно находится в 15 метрах от персонажа и к моменту достижения горизонта должно быть уже не видно. Зато получилось проблему с отражениями ночью решить.

У меня в нужном месте находятся.Здесь проблема больше со стилистическим восприятием. Теоретически, можно шейдеры подшаманить, но я здесь не помощник. Ну так исходный пост был о том, что солнце возникает из ниоткуда над горизонтом. Но оно как раз возникает ЗА горизонтом, восходит, а его лучи постепенно теряют прозрачность. Не знаю, что здесь можно сделать. Фактически, ночью тупо движется в обратную сторону, пока его не видно, и просто так показать его раньше нельзя.

Это вот это - отражение солнца? Это же вроде отражение одной из лун, появляется примерно в 23:00 По поводу появления солнца над горизонтом - вы настройки в INI не меняли? Судя по коду, оно должно появляться возле горизонта полностью прозрачным, затем прозрачность постепенно снижается до нуля. Собственно, у меня так и происходит. Не знаю, как ведет себя оригинальный движок.

В основной ветке поведение такое же, или это я накосячил?

В принципе, исходники MGE открыты: https://github.com/Hrnchamd/MGE-XE/tree/master/src/mge Теоретически, можно сделать по аналогии, но там используется DirectX, а в OpenMW - OpenGL.

Когда его кто-то сделает. Пока желающих не наблюдается.

Тем, что его пока OpenSceneGraph не поддерживает. Характеристики в ESM-файле, вращение зашито. Иначе 42.

Изменения погоды в зависимости от времени суток были зашиты и более-менее подогнаны под эффект при настройках по умолчанию.Я добавил обработку этих настроек: fallback=Weather_Sky_Pre-Sunrise_Time,.5 fallback=Weather_Sky_Post-Sunrise_Time,1 fallback=Weather_Sky_Pre-Sunset_Time,1.5 fallback=Weather_Sky_Post-Sunset_Time,.5 fallback=Weather_Ambient_Pre-Sunrise_Time,.5 fallback=Weather_Ambient_Post-Sunrise_Time,2 fallback=Weather_Ambient_Pre-Sunset_Time,1 fallback=Weather_Ambient_Post-Sunset_Time,1.25 fallback=Weather_Fog_Pre-Sunrise_Time,.5 fallback=Weather_Fog_Post-Sunrise_Time,1 fallback=Weather_Fog_Pre-Sunset_Time,2 fallback=Weather_Fog_Post-Sunset_Time,1 fallback=Weather_Sun_Pre-Sunrise_Time,0 fallback=Weather_Sun_Post-Sunrise_Time,0 fallback=Weather_Sun_Pre-Sunset_Time,1 fallback=Weather_Sun_Post-Sunset_Time,1.25 fallback=Weather_Stars_Post-Sunset_Start,1 fallback=Weather_Stars_Pre-Sunrise_Finish,2 fallback=Weather_Stars_Fading_Duration,2 Они работают в комплексе с настройками времени заката и восхода и влияют на скорость переходов.

Уже неплохо.Основная проблема в том, что сухопутные анимации поворота слишком длинные, чтобы проигрывать их целиком, к ключам привязаться я не могу из-за багов в самих анимациях. Вот и пришлось в код зашить - проигрывать 40% от сухопутных анимаций, 80% от поворота в воде.

Да, желательно посмотреть, как выглядит. Вроде бы удалось получить приемлемый результат.

Пытаюсь расхардкодить закаты и рассветы в OpenMW: https://github.com/a...weathersettings Вроде работает, но нужны эстеты для сравнения с оригинальной игрой, особенно с нестандартными настройками. Есть здесь такие? Плюс здесь вроде какой-то мод на темные ночи есть, неплохо бы и его проверить.

Сейчас вся погода в код зашита. Разве что если кто-то ее потом настраиваемой сделает...

Там проблема в том, что навмеши генерируются в основном потоке, а это может занять несколько секунд. В качестве решения предлагается генерировать их в отдельном потоке, а пока они не сгенерировались, использовать старую систему (pathgrid). Возможно, эту фичу придется сделать отключаемой, т.к. она может снизить производительность на слабых машинах, особенно это касается порта для Android.Также пока эта фича не чинит AiWander (хотя это решаемо) и уклонение в бою (там вообще поиск пути не используется, персонаж тупо бежит назад или в сторону). Не экипировали, но не забываем про переходы между погодой - дождь реально мог еще идти, хотя движок считал, что уже ясно и персонажи доставали факелы. Я же проверяю реальное наличие осадков.

Если имеется в виду именно сопротивление магии, то нет. Но там был свиток защиты от магии, но он вообще не давал персонажу применять никакую магию, поэтому такие свитки обычно применяли для обкаста воинов перед схватками с Очень Злыми Магами. К поглощению заклинаний это имеет довольно посредственное отношение. В продолжение темы с анимациями поворота: пытаюсь сделать, чтобы анимация проигрывалась полностью, а не прерывалась.Только есть проблема: ключ "stop" расположен примерно на 80-90% времени анимации, а не 100%. Там разве еще какие-нибудь ключи есть? Пока что работаю через костыли, для поворота при плавании проигрываю 80% от анимации, для сухопутных анимаций - 40%. Вот что получилось: https://github.com/a...mw/tree/animfix Может кто-нибудь протестировать? UPDATE: Оказалось, что у анимации SwimTurnLeft нет ключа "loop stop", зато есть два "loop start". Копипаста такая копипаста.

Странно. Только что архив скачал, файл от 11 марта, 2.5 Кб. Яндекс чудит?

Странно. Я там один файл заменял, как раз патч. Точно старый?

Именно поэтому в OpenMW оставлено, как есть. Факелы сейчас тоже экипировать заново не надо, в отличие от оригинальной игры. Плюс в OpenMW найдено интересное поведение, уж не знаю, ведет ли себя Морровинд также. При ударе случайно по персонажу выбирается предмет доспеха, который надо повредить. С вероятностью 5% это щит. Если он не экипирован вообще, то будет звук удара по телу и броня не повредится. Если экипирован, то будет звук удара в соответствии с типом брони, и щит будет поврежден, даже если его нет в руках персонажа. Также у меня была идея использовать не общий класс брони для всего тела, а отдельный для разных частей (например, кираса не будет уменьшать урон при попадании в ногу). Проблема здесь в том, что пока нет возможности определить, куда конкретно пришелся удар - сейчас оно выбирается абсолютно рандомно.