О следующем проекте

Есть важный разговор по поводу следующего проекта.

Мне нужно узнать, как много из вас до сих пор пользуется LE версией игры, и если пользуетесь, то готовы ли вы перейти на SE\AE версию, когда в будущем я выпущу первую часть следующего проекта (это будет не скоро, но мне важно уже знать сейчас).

Дело вот в чем: несколько месяцев назад я впервые решил попробовать создать SKSE плагин. С++ я не знаю, по этому никогда и не пробовал туда соваться. Но сейчас есть нейросети, которые уже очень хороши в кодировании, и могут быть хорошим помощником. Было просто интересно, как это работает, ведь за столько лет моддинга Skryim я ни разу даже не пытался. После долгих разбирательств с технической частью, у меня получилось создать свой первый skse dll плагин, из которого я мог в игре дергать функции, чему я был бесконечно рад :)

На мое удивление, оказалось, что SKSE предлагает почти полный аналог API papyrus, конечно, с синтаксическими особенностями С++(все эти ссылки, указатели, шаблоны и тд.) но сам вызов функций вполне привычен и интуитивно понятен. По сути, могу там писать аналог папирус функций почти для любых задач. Конечно, с хорошим знанием языка и Reverse Engineering там открываются куда большие возможности, но даже без этого можно извлекать огромную пользу, ведь функции выполняются на много порядков быстрее, и можно перекладывать на плечи SKSE тяжелые инструкции, тем самым разгружая папирус и ускоряя выполнения критически важных участков различных механик. Особенно это важно в SE версии, где папирус в сотни раз медленнее, чем в LE, из-за того, что ему выделено значительно меньше процессорного времени на кадр.

К тому же, есть много функций, которым попросту нет аналогов в papyrus. Пара примеров, из того что я уже обнаружил:

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

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

• В папирусе нельзя получить смежную ячейку в экстерьере стандартными способами, если это нужно делать динамически. Например, стоит задача: найти всех персонажей вокруг игрока, и вернуть массив, дополнительно отфильтровав по разным параметрам. В папирусе алгоритм костыля будет примерно такой: мы знаем размеры ячеек, знаем положение персонажа в мире игры, можем вычислить математическими операциями центр текущей ячейки, потом расположить 8 маркеров так, что они гарантировано попадут во все смежные ячейки с текущей, потом пройтись в цикле по маркерам, вернуть их ячейки, сформировать массив, и затем в цикле пройтись по каждой, где провести нужные фильтрации. Я такую функцию писал, и она выполнялась более 10-ти секунд. Что неприменимо почти нигде в реальных задачах. А если нужно искать во всех загруженных ячейках (5х5 для Скайрима по умолчанию), то это время нужно умножить минимум на двое. Конечно, я такое никогда не использовал в игре, но тут скорее от обратного, не использовал, потому что изначально не создавал такие события, в которые подобное могло бы пригодиться. А когда все же нечто подобное мне нужно было, например в Маркарте, быстро находить и прятать NPC, которые в любом момент могут выйти из любого здания, я использовал костыльные методы через триггеры, помещая их в массив и весь массив с цикле постоянно перемещать в край локации, чтобы их не было видно, а по окончании сцены, перемещать их по домам. Можно было запариться и поместить всех существующих в Маркарте NPC заранее в массив, но тогда не учитывались бы те, что были добавлены сторонними модами. В SKSE же можно просто вернуть все ячейки через структуру, которая их хранит, сделать любые фильтрации сколько угодно сложные, и получить мгновенно результат.

• Многострадальное масштабирование игрока: тут думаю комментарии излишни, учитывая как много раз я об этом ранее упоминал, и сколько крови мне эта вещь попортила. Во-первых, в SE версии игры исправлен баг с гонкой условий, что устраняет вылеты при вызове setscale, но в SKSE мне даже не надо дергать setscale или getscale (первого там даже нет, насколько я понял, или я просто не нашел), мне не надо высчитывать модификатор расы, путем применения дважды setscale, его можно получить, но это даже и не нужно, я меняю размер 3D модели напрямую, при чем это можно делать плавно, что будет незаметно в игре, обновляя каждый кадр. Никаких больше резких скачков роста. Да и к тому же, если что-то пойдет не так, и размер не сбросится в дефолт после сцены, это случится при выгрузке персонажа из ячейки или загрузки сохранения, потому что эти данные не сохраняются. Я могу применять различные эффекты, можно делать очень плавно и незаметно, или даже какие-то карикатурные.

• Анимации: я могу вызывать анимации на любом количестве персонажей одновременно в рамках одного кадра, с любыми параметрами. Что может избавить нас от одной из самых больших нерешаемых проблем в папирусе - рассинхронизации. Но это не точно, я еще не проводил достаточно тестов. Хотя в тех, что проводил, анимация всегда была идеально синхронизирована. Если взять обычный папирус, то я вызываю функции одна за другой сразу же, с уже заранее подготовленными параметрами, чтобы это было максимально быстро насколько это возможно, и все равно анимация часто сильно расходится. Иногда она синхронизирована идеально, иногда сильно отстает, я не знаю от чего это зависит, возможно у менеджера анимации есть такты, и если один персонаж не попал в свой он долго ждет следующий. И эти такты не так часто судя по всему происходят, учитывая, что анимация одного персонажа может отставать от другого вплоть до 10-15 кадров. Еще наверное зависит от производительности железа, на SE версии, где у меня меньше фпс, по ощущениям шанс рассинхронизации значительно выше. SKSE почти гарантировано избавит нас от этой проблемы, или сделает ее значительно меньше.

• Прикрепление персонажей к координатам. В папирусе это большая проблема, потому что нет нативной функции и приходится использовать костыли. В Воришке я использую setvehicle, ту функцию, что прикрепляет персонажа к тележкам, она хорошо работает, надежно прикрепляет персонажа к координатам, так, что даже после загрузки он там остается висеть :) но в момент прикрепления это происходит резко, с рывком, к тому же ломается скейл, который надо костылями чинить, также от персонажа исходит havok импульс разбрасывая вокруг предметы, что добавляет мне работы во время создания сцен, приходится все предметы вокруг заменять на их статичные копии. Есть еще один подход, использовать translate, это то что я хотел использовать в будущем проекте, и буду, если не перейдем на SE, там можно делать плавно, но остается проблема с колизиями, окружающие предметы могут как бы скользить, постоянно смещаясь куда-то в сторону. И все это ни в какое сравнение с тем, что можно делать на SKSE. Я смогу делать очень плавный входы и выходы из анимаций не просто линейно, а с плавным затуханием, что сделает движения более реалистичными.

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

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

Я уже переписал себе логера на базе SKSE, потому что мой работал в 5 раз медленнее, чем нативных trace. И это могло стать проблемой во время отладки мини-игр, где счет на кадры. Я смог его расширить и сделать еще более удобным, помимо ключей добавил еще и уровни, и все работает по скорости базового. Я им в любом случае буду пользоваться, потому что это та вещь, которую в релиз мне не нужно добавлять, буду просто ставить заглушку.

Раньше SKSE требовало обновления плагина после выхода новой версии игры, что в первую очередь всегда убивало у меня желание попробовать, но сейчас это решено, как я понял, начиная с какой-то там версии dll-ка будет подходить к любой последующей.

В общем, это все только малая часть того, что я обнаружил, но наиболее значимая.

Естественно, когда я впервые понял, что это прямо супер крутой инструмент, который может позволить сделать мне по настоящему удобный инструментарий с возможностями, которых прежде не было, я полез искать SKSE для LE. Настроил его для работы, что тоже было не так просто, и тут случился облом. В LE версии вообще все по другому, и надо заново разбираться, а во-вторых, там нет и малой части тех функций, которые есть в commonlibSSE NG. Это совершенно разного уровня функционал. Я почему-то думал, что он одинаковый, но нет. Я не могу написать код на SE потом скопипастить его на LE и чтобы он работал, нет, там большинство вещей unknown и надо самому искать адреса в памяти, чего я делать не умею, а если бы и умел, полагаю, на это ушло бы очень много времени.

Так что варианта тут всего три:

• 1) Самый очевидный - не использовать SKSE. Что в общем-то не так критично, я все же работал как-то без него столько лет, и еще поработаю. Как-то глобально не особо скажется - все что нужно у меня есть и на обычном папирусе. Просто иногда придется, как и раньше, посидеть, поискать пути решения различных задач подольше.

• 2) Создавать свой будущий проект только под SE, отказавшись полностью от поддержки LE. О плюсах я написал уже выше. Это будет шаг вперед, и откроет мне новую ветку развития(с++), которую придется качать, но с прокачкой будут появляться и новые возможности. Но уже в самом ее начале имеются весьма недурственные плюшки.

• 3) Ну и самый сложный для меня: для LE и SE создавать отдельные версии фреймворка. И почти наверняка я это не выберу, хотя все еще рассматриваю. Это будет слишком большая нагрузка, а отладка это будет вообще отдельная песня.

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

Но если кто-то не хочет, или не сможет перейти на SE, я тогда продолжу писать его на чистом папирусе, и не буду отказываться от LE. Это не станет проблемой для меня, я сам привык к LE версии, по разным причинам она мне нравится, я на ней 99% времени, только тестирую на SE. Так что если вам тоже по своим причинам нравится LE, и вы точно не перейдете на SE ни при каких обстоятельствах, не стесняйтесь голосовать за эту версию.

И как всегда, огромное спасибо за вашу поддержку!