ArtemSH

Я случайно наткнулся на это обсуждение. Воспринимайте эти соображения как "круглый стол" или конференцию. Вопрос о преобразовании оригинальных локаций будет стоять всегда, а рассуждения наших французских коллег мне показались не лишенными смысла, поэтому данный перевод имеет цель подогреть дискуссию по поводу Имперского Города и его реализации в игре, а также поспособствовать вдохновению для тех из новых поколений моддеров, кто когда-нибудь возьмется за преобразование города снова. примечание переводчика Рассуждения иностранцев не лишены практического смысла, а упоминания многих модификаций, часть из которых уже толком подзабылась, пригодятся тем, кто ищет какие-нибудь интересные "скрытые сокровища" (hidden gem) в безбрежном океане нексусных модов. как нам реорганизовать имперский город? (benorun974) Вот несколько соображений по улучшению Имперского Города. Я всегда был расстроен тем, как город изображен в игре, несмотря на существование таких модов как Better Cities, Unique Landscapes - Imperial Isle или Region Revive - Lake Rumare. Город всегда был далек от лора игры. В основе оригинальной концепции города заложено представление о городе-на-островах в духе Венеции. Примерно в таком стиле: Концепт-Арт Очевидно, что это скучноватая работа, и я вообще не представляю, возможно ли технически перенести районы города во внешние ячейки. Проблемы города На данный момент я хочу указать на несоответствие между имперским островом и городом в целом: Ландшафт Почему город настолько приподнят по сравнению с уровнем воды? Модифицированный Город Мост Талоса Мост Талоса вообще смехотворен: разница положения над уровня моря между мостом и вратами города слишком велика. По такому отвесному склону сложно подниматься хоть верхом, хоть в повозке, хоть пешком. UL пытался решить ситуацию, создав зигзагообразную дорогу к городу, но в результате больше нельзя разглядеть входные врата, и парадная дорога к городу начинает выглядеть менее монументально (если только не добавить туда зданий). BC добавляет туннель между портом и храмовым кварталом; склон аналогично слишком крут, так что в таких условиях транспортировка товаров усложнена (к тому же следует еще пересечь весь город чтобы добраться до торгового квартала). Мост к Городу Положение районов Зачем располагать Торговый Район на противоположной от порта стороне? В этом нет никакой логики. Что следовало бы сделать? Сперва наперво: сместить или переставить районы города. Торговый Район на место Храмового Района. Храмовый Район на место Дендрария. Дендрарий на место Арены. Арену на место Торгового Района. Я полагаю, что такое вполне возможно сделать, поскольку это упирается в манипуляцию с дверями ячеек и перемещении внешней стены Арены на место внешней стены Торгового Района. Для этого стоило бы и исправить карту чтобы отразить наше новое расположение кварталов. Для ландшафта не знаю можно ли понизить весь остров целиком или это надо делать вручную? Для внутренних ячеек вполне может быть использован BC, хотя это как посмотреть. подходы к реализации Объяснюсь. Есть два подхода к модификации города. Мы можем рассмотреть реализацию города подобного плана: Арт Арт Арт Город будет полон воды, а каналы будут пронизывать весь город, служа для транспортировки жителей, торговцев и их товаров. Такой подход потребует переделки всего города и увеличения районов в размерах. В таком случае ни BC, ни другие моды не будут больше совместимы с такой переделкой. Основой (и обьектом вдохновения) для такой реализации города может служить следующий мод: New Imperial City. Я опробовал его, некоторые районы великолепны, но мод полон багов (вылеты при входе в некоторые новые районы, особенно распространенные при входе в некоторые здания, невыразительные районы, такие как Дворцовый Район и так далее). Оригинал (с модами на мосты) Новый Город из New Imperial City Оливер Твист был бы счастлив Подобие вертикального лабиринта Дворцовый Район Канализация Новый Район Тренировочная Площадка Район Корабельного Производства Другой подход состоит в том, чтобы не модифицировать внутреннюю часть города, сохранив совместимость с BC (если хочется), за исключением районов, как описано выше. Может быть просто добавить несколько каналов в город для красоты, бассейны или водопады по стенам, как в Imperial Waters, который больше не совместим с BC. Торговый Район был изменен и улучшен благодаря RedBag. Imperial Waters Waterfront (RedBag) Огни Городских Башен (RedBag) Торговый Район (RedBag) реализация каждого района С другой стороны, хорошим тоном было бы добавить к городу пригород с разными районами, в разных архитектурных стилях, с разными отличительными чертами. Рисунок автора Начнем с Портового Района Как вы можете видеть на карте, которую я перерисовал (не смейтесь, я не умею рисовать), порт следует расширить и углубить дальше в остров. Округлый, он будет примыкать к Торговому Району, упрощая доставку товаров. Пускай он будет включать в себя пристань с различными постройками, например, судовладельцев, портовой таможни, морского гарнизона, новых кораблей и т. д. Возможно следует добавить здание, служащее для конструирования флота (смотри скриншоты мода New Imperial City). Окружающие дома, по сути, будут рыбацкими хижинами на сваях, а каналы пройдут через окрестности. Вот такой мод может служить основой для этого: RAWaterfront. Район следует разделить двумя стенами, охраняемыми по концам, ведь район довольно таки беден и небезопасен по ночам, поэтому там процветает контрабанда и параллельный импорт. RAWaterfront RAWaterfront RAWaterfront RAWaterfront Университет Волшебства Пусть он примыкает к Храмовому Району на юге и к Дендрарий – справа. Схожим образом разделенный двумя стенами, портовой и северной, он станет большим парком, созданным для медитации, идеальным для университетских магов и молитвенников Храмового Района. Он будет состоять из маленьких водоемов, водопадов, зелени, статуй, фонтанов и тому подобного. Также стоит добавить и здания монастырей, общежитий для студентов университета и отелей для паломников. Вот подобного рода мод следует инкорпорировать: ICAU_Mages_Bridge. Тюремный Район Пусть он примыкает к Арене, некоторые заключенные могут послужить в качестве комбатантов на Арене. Тюрьма будет окружена водой чтобы лишить узников возможности сбежать. Возможно мост к тюрьме следует совсем убрать, а добираться до тюрьмы надо будет только под конвоем – на пароме или лодке. А вокруг пусть будут солдатские казармы, комнаты или площадки для тренировок и тому подобное. Аристократический Район (на севере) Он добавлен BC. Изрезанный каналами, ему следует выглядеть немного побогаче, напоминая Венецию (как источник вдохновения). Вот такие моды могут служить основой или референсом: Avelee City Exteriors Imperial City Suburbs Shezrie's Towns (по архитектуре) RedBag - Imperial City Pack  (по экстерьерам) Avelee City Exteriors Avelee City Exteriors Avelee City Exteriors Imperial City Suburbs Imperial City Suburbs Shezrie's Towns Shezrie's Towns Shezrie's Towns Shezrie's Towns Район следует также отгородить стенами, а по нему раскидать многочисленные патрули, ведь район довольно богат. Я представляю себе целую сеть разветвленных трущоб, прорезывающих остров здесь и там, и находящихся, в том числе под мостами. Дома должны быть по обе стороны мостов, но здесь я хотел продемонстрировать сам принцип расположения трущоб на мосту. Трущобы облюбовали и сам мост и пространство под ним. Я подумывал продолжить фетишизм районов-кругов, хоть это и нереалистично, но зато я бы добавил побольше забитых барахлом трущоб. Вот такая монолитная, но завешанная барахлом архитектура Города видится мне подходящей. Мосты на вторых этажах позволят НИПам перемещаться напрямую между зданиями. Мост Талоса Этот мост, как я уже говорил выше, просто смешон. Коль скоро он примыкает к низине имперского острова, ему действительно стоит быть похожим на то, что мы видели в моде Talos Bridge Gatehouse. Иначе ему следовало бы выглядеть как-то вот так. На въезде можно разместить знаки, указывающие путь тем, кто перевозит товары, в порт и торговый район, где расположено большинство складов. На дорогах и вокруг городских ворот также можно будет разместить торговые караваны, чтобы создать ощущение экономически процветающего города. Talos Bridge Gatehouse Talos Bridge Gatehouse Многоярусный город Вот, что пришло мне на ум чтобы улучшить Имперский Город. Скажите мне, кому интересно таким заняться? Возможно ли это технически? Какие идеи хороши, а какие нет? Чего придерживаться, а что отбросить? И какие моды следует включить или использовать их материалы для того, чтобы сберечь время? Обсуждение Дополнение от участника (А.): Фактически, районы уже находятся во внешних ячейках, каждый закрытый район (те, для доступа к которым требуется пройти через дверь) расположен в независимом Worldspace (Worldspace indépendant), остальные расположены в общем Worldspace (Worldspace général). Эти закрытые районы довольно легко перемещать между собой и даже расширять при необходимости, поскольку если их Worldspace не очень большой, в нем будет всего несколько ячеек. В дальнейшем именно согласованность с пропорциями за пределами города рискует стать проблемой, хотя при небольшом мошенничестве это будет не так уж и заметно. Ну кстати это уже кому как. Перепланировка внутренних ячеек этих районов также возможна, при условии сохранения ссылок, дверей и т.п., которые можно переместить. Повторное использование существующих модов кажется мне действительно утомительным занятием, поскольку разрешения некоторых из упомянутых вами модов четко указывают на то, что их нельзя частично использовать повторно. Можно также воспользоваться свободными ресурсами, которые по определению довольно легко интегрируются. ПС: Вот собираюсь взглянуть на два района. Думаю, пропорции сохранятся при перемещении, но дизайнеры в них нюансируют текстурирование, чтобы связать внутренние ячейки районов и внешние ячейки внестенных элементов ландшафта. Дополнение от автора (benorun974): Если внутренние районы можно расширить, то идея каналов внутри города будет более уместной и, возможно, проще в реализации. Потому что пригород, как я и предполагал, на севере (со стороны аристократического района) резко понизил бы FPS (уже в BC добавление 2 лодок в порт заставляет игру лагать...). Возможные идеи, которые можно оставить:  - Понижение ландшафта острова - Каналы внутри городских стен - Изменено расположение районов для большей единообразности. - Круглый порт, примыкающий к Торговому Району, с каналом, входящим в район: необходимо сделать входы в виде дверей, которые будут отражать внутреннюю часть района, не открываясь (не знаю, понятно ли я выразился). Небольшой рыбацкий район с домами на сваях и небольшими каналами/реками. - Тюрьма, изолированная водой со всех сторон (типа Алькатраса :) ), с несколькими солдатскими постройками. - Благоустроенная территория вокруг Университета Волшебства. - Чуть более грандиозный Мост Талоса. Что касается упомянутых мной модов, то я бы скорее вдохновлялся ими, чем использовал бы их вместе, хотя некоторые из них уже не находятся в разработке (RedBag, New Imperial City). Дополнение от автора (benorun974): У меня есть нова мысль по моду, более простая  и требующая «меньше» работы. На самом деле проще сделать компиляцию уже существующих модов, не затрагивая ландшафт. Несколько общих соображений, а затем я перейду к более подробной дорожной карте: - Основой сборки будет BC как для существующих районов, так и для внешних ячеек. - Добавить парочку новых районов из New Imperial City: бедный район между мостом Талоса и портом. Еще другой такой же бедный район между Университетом Волшебства и Ареной и еще один между Ареной и Мостом Талоса. - Расширение порта и добавление к нему закрытого рынка ближе к городу. - Переработка Моста Талоса. - Интеграция Imperial Waters в существующие районы BC. - Интеграция модов с внутренними ячейками некоторых новых районов: бордель, подозрительный бар и т. д. - Получим доступ к отдельным модам, уже встроенным в BC, о которых я расскажу потом. Плюс к тому, еще размещение новых кварталов во внутренней ячейке позволило бы не терять FPS, а еще ведь пришлось бы выравнивать ландшафт и убирать объекты из декораций на их местах. (то есть автор хочет расставить эти районы не в городском Worldspace, а в совершенно не привязанном к миру Тамриэля, для совместимости с плагинами, изменяющими сам остров - ArtSH.) Дополнение от Переводчика В ходе своего обсуждения моддеры упомянули несколько неизвестных модов, чья концепция меня заинтересовала так же, как и французских коллег. Действительно, каждая глобальная переработка Имперского Города или Ватерфронта вносила своё собственное видение этих поселений, но выработать на основе сделанного общую картину, дизайнерски обьединявшую все это море разрозненных модификаций так и не получилось. Better Cities, на мой взгляд, получился не столько громоздким, сколько недоделанным. Несмотря на все старания поддерживающего мод Vorians'a, квестовые линейки мода остаются неоконченными, некоторые кварталы городов кажутся лишними или пустыми, другие - очень захламленными. Но Аристократический Район это действительно находка, так же как и идея встроить в BC Cyrodiil Rebuild, блестящий мод, задающий высокую планку для всех, кто пойдет следом.   Better Cities Better Cities На перевод этих мыслей меня вдохновил недавно вышедший мод Imperial City - Unique Buildings, который кроме введения новых элементов в Имперский Город еще и изменил текстуры зданий в каждом районе отдельно, отчего теперь текстуры у зданий в каждом районе свои, уникальные, а значит и общий вид города стал разнообразнее, ярче. В таком изменении есть свой резон, хотя далеко не всем придется по душе отказ от единообразной расцветки Имперского Города, ведь этот дизайн явно напоминает Минас Тирит Джексоновской трилогии Властелина Колец, поэтому есть в это белом камне своя стать, "её аршином не измерить". Талос Плаза (гифка) Эльфийские Сады (гифка) Храмовый Район Торговый Район Фонтан Эльфийских Возлюбленных Центр Университет Волшебства Тюрьма Красиво, правда? А ведь до этого момента таким Имперский Город еще никто не делал! Идея лежала на поверхности! И автор, объединив воедино множество подходов и модификаций от предыдущих "поколений", добавил своё общее виденье и создал уникальную вещь. Вот потому и я перевел эти мысли. Ведь, в конце концов, действительно, почему Торговый Район еще не перенесли на место Храма? А Храм на место Арены? А Арену, действительно, на место Торгового Района, поближе к Тюрьме? Ведь это само напрашивается. По другому и быть-то не могло! Но нам остается ждать, пока кто-то не возьмет на себя труд сделать эту неблагодарную работу. Но пока я готовил этот материал, на ум начали приходить самые разные моды, которые я уже видел да позабыл. Когда я прочел про остров-тюрьму, я сразу же вспомнил, что такой мод уже есть: The Imperial City Isles. В соответствии с картой из демо-версии автор сделал Университет и Тюрьму отдельными островами. Теперь убежать из такой Тюрьмы действительно нетривиальная задача, и выглядит-то как монументально! Мост Мост К такому острову теперь и мостов хотелось бы побольше! И мосты есть: Imperial City Bridges Extended. Панорама Три новых моста RedBag, упоминавшийся выше, выпустил облегченную версию своего Имперского Города: RedBag's Imperial City - 2020 Edition. Добавил уйму деталей и в районы в Ватерфронт, но, по сути, такую версию встроить в глобальную солянку проще, чем оригинал.   . Ватерфронт Талос Плаза Арена Дендрарий А если бы обьединить всё это с Imperial Ciry Suburbs да с FOMO - Imperial Isles - Heart Of The Empire, добавлявший отдельный Восточный Порт, эдакий Ватерфронт, но для богатых со своей гильдией и, если не ошибаюсь, квестами. И как шикарно он сделан! К этому всему еще и упоминавшийся Region Revive Rumare, добавляющий тут и там деревушки, часовни и квесты! Тогда Имперский Остров просто зацветет жизнью, обретет второй дыхание. Получит, наконец, своё собственное лицо. Ватерфронт же, этот грязный уголок в самом сердце Империи, много раз переделывали. И много раз успешно. Серьезно, многие интепретации этого места от моддеров мне кажутся весьма и весьма удачными. Но всё-таки пока что в сердце у меня осталась толька одна версия: Muggrug's Waterfront Overhaul. Мод отличный, особенно важно, что он затрагивает только четверть от всего Ватерфронта, а именно саму деревушку, превращая её в подлинный шедевр. Совместимость и грандиозность - вот, чем подкупает этот прекрасный мод... Южная часть обновленной деревни Трущобы Площадь Обновленная деревня Новый Дом Игрока Ватерфронт Новые Доки Новые Трущобы ....и, к сожалению, больше не доступный для скачивания. А жаль! Может быть, еще не вечер. Он превращал район в интересный лабиринт трущоб, где сочный стиль упадка сочетался с функциональными доками, куда могут пристать корабли. На мой взгляд здесь зашкаливает атмосферность этого места, а Гильдия Воров наконец-то проводит собрания не в каком-то невыразительном тупике, а рядом с подчеркивающим торжественность момента монументом. С другой стороны, трущобный дух Ватерфронта хорошо выразил и New City IC Waterfront. Расхристанные улицы, подсобное хозяйство с овощами прямо под боком крупнейшего мегаполиса страны, заваленные бочками тротуары. Бардак И красота Чего-то похожего добивался и Momos Harbor Expanded, но, как по мне, малость переборщил. Хотя эти краны и навесы над тротуарами выглядят интересно, может кого и вдохновит похимичить с улицами для обретения нового уникального облика этого городка. Я хотел было составить целый список модов, которые можно было бы собрать в единый сборник. Или на худой конец вдохновляться для собственной глобальной переделки. Но меня ждал очень неприятный сюрприз: как минимум половина из них уже недоступна при поиске. Поэтому я решил ограничиться лишь одним упоминанием такого мода, но их было гораздо, гораздо больше! На этом и я с вами прощаюсь, читатель. Я считаю, что важно иногда делать такие подборки, вспоминать, что было сделано сообществом за все эти годы, пытаясь вычленить из модификаций что-то хотя бы концептуально полезное для общего дела. И пусть даже такой поверхностный обзор будет подспорьем как для искателей интересных модов, так и для творцов, ищущих показательного примера.

NothernUI выпущена уже более трех лет назад, и мне кажется, что я хочу поделиться некоторыми соображениями по поводу его разработки, трудностями, с которыми я столкнулся, вещами, которые я мог и должен был сделать лучше, и тому подобным. Я не хочу использовать понятие «пост-мортем», поскольку я не хочу списывать со счетов своё каждое возвращение к NothernUI, но я полагаю, что данный текст будет подобием отчета. Фронт работ и переизбыток функционала Однозначно наибольшая и худшая проблема NothernUI. Мы не говорим о переизбытке функционала (feature creep), как он представлен в Oblivion Reloaded, но NorthernUI все-таки предлагает слишком много всего в одном моде, что совершенно точно должно было быть разделено на несколько модификаций. Наибольшее сожаление у меня вызывает поддержка геймпада наряду с другим функционалом в едином DLL, и именно она и стала источником переизбытка функций. Единственная причина почему я имплементировал поддержку геймпада заключалась в том, что Xpadder/AntiMicro не мог удовлетворительно работать в меню игры. Единственный способ плавно управлять переключением между геймплеем и меню был в том, чтобы иметь действительно встроенную поддержку геймпада в игре. К сожалению, я был незнаком с тем, как Windows API работают с DLL. Я выучил С++ и Ассемблер х86, делая SKSE плагины, и SKSE, не как OBSE, предлагает простой механизм отправки сообщений между плагинами, так что я никогда и не нуждался в том, чтобы выучить Windows API. (по сути, когда дело доходит до С++, я учил всё самое сложное и нюансированное в первую очередь, всё самое легкое – в последнюю). Я не знал, как передавать сообщения между плагинами OBSE, так что, как по мне, всё, что нуждалось в доступе к состоянию геймпада, должно было быть частью единого DLL, так что поддержка геймпада встала на первое место. Вот поэтому такие функции как улучшенное движение и контроль камеры оказались в том, что должно было быть просто рескином UI. Для тех, кому интересно, правильно было бы сделать поддержку геймпада полностью отдельным OBSE DLL и заставить его «экспортировать» функции, которые бы вызывались другими DLL. Тогда любой заинтересованный OBSE DLL мог бы использовать GetModuleHandle и для проверки (check) загружен ли DLL геймпада и для того чтобы получить доступ к экспортированным функциям посредством GetProcAddress. С таком системой такой функционал, как улучшенное движение и поведение камеры, был бы частью еще одного DLL, тем самым всё было бы аккуратно отделено друг от друга. (Ох, говоря об этом: не находите камеру игры некомфортной и дезориентирующей? Не бесит ли вас, когда камера стрейфится, пытаясь заглянуть в сторону вашего движения, да так, что движение диссинхронизируется с камерой? Достали каждый раз возникающие резкие раскачивания камеры при беге через бордюр? Отключите опцию NorthernUI "Camera Inertia" чтобы убрать «головокружительный» опыт. Я буквально забыл, что сам же это и придумал, и обнаружил это только сегодня, и ё-маё, как же лучше игра воспринимается теперь! Я так благодарен за то, что в Скайриме этой инерции камеры больше нет. Я всё еще оставляю её включенной (но с фиксами), как настройку по умолчанию, поскольку Обливион остается Обливионом и должен быть Обливионом по умолчанию.) Если бы мне пришло в голову полагаться на этот вид связи с DLL, я мог бы также позволить NorthernUI предоставить API для своего меню параметров: я мог бы определить классы «обработчиков опций» (option handler) с виртуальными функциями-членами и позволить NorthernUI получить указатели (pointers) на их экземпляры (instances). Другие DLL могли бы определить свои собственные под-классы, которые перезаписывали бы эти функции чтобы специфицировать тип виджета опции (чекбокс, слайдер, т.п.), содержать значение, реагировать на изменение значения и тому подобное. Эту идею можно было развить и дальше, позволив другим DLL вставлять вложенные структуры меню (to insert nested menu structures). Если бы я отделил мое улучшенное движение и патчи для камеры каждый в свой собственный DLL, они бы могли использовать такой фреймворк. Это было бы полезно и для многих других DLL-модификаций в Обливионе. (Однажды я таки рассмотрел логистику, позволяющую скриптам добавлять пункты меню в меню параметров, но я не смог придумать хороший дизайн API для них.) Схемы Управления NorthernUI включает в себя несколько пред-определенных (pre-defined) схем управлениях и позволяет вам выбрать один из них. Я не думаю, что постарался правильно презентовать эту функциональность, но уж точно на совесть потрудился имплементировать её в игру. Этот подход был вдохновлен играми на подобии Halo, где игрок имеет широкий выбор схем управления, акцентирующих внимание на разных действиях и способностях, таких как иконический Bumper Jumper, предполагающий, что игрок прыгнет и нанесет удар без того, чтобы пришлось убирать для этого пальцы со стиков джойстика. Я хотел предложить несколько хороших схем управления, но также и дать игрокам возможность сделать свои. Насколько помню, в Borderlands 2, напротив, дают немножко уже созданных схем управления, позволяя игроку просто сделать одну свою кастомную, что несколько сужает выбор, но, быть может, интуитивнее того, что создал я. Оглядываясь назад, я понимаю, что было бы сподручнее, если бы игрок видел перед глазами схему геймпада от Xbox с лейблами, привязанными к каждой кнопке чтобы игрок мог буквально увидеть различия стилей. Однако в нынешнем виде я думаю, что внешний вид меню настройки не уступает остальным меню Oblivion. Однорукие схемы управления – вещь, которой я вполне горжусь. Они были вдохновлены прямо и полностью спидраном нескординированного бега в NieR:Automata у Games Done Quick. Я пытался задизайнить каждую схему управления так, чтобы большая часть критически важного для геймплея функционала была доступна легко и быстро, хоть я и не настолько опытен в играх, чтобы бросить им вызов самому. Я едва двумя-то руками управляюсь. Вызовы Совместимости Трудности в вопросе совместимости, которые появляются при создании рескина UI, это то, чего я совсем не предусмотрел. Оказалось, что просто куча скриптовых модов опираются на доступ к UI чтобы изменить состояние игры и её функционал, а скриптовые функции, на которые эти моды опираются, впечатляюще хрупки. UI-команды и у OBSE и у MenuQue требуют чтобы элементы UI были доступны по полному пути (fully-qualified path). Это значит, что, измени я структуру элементов (how elements are nested) или измени я название любого элемента, вложенного в эту иерархию, тут же эти команды перестанут работать. Некоторые из авторов этих модов включали в код автоопределение DarNified UI и использование отличающихся путей к элементам под него. Мне приходит на ум один автор, включивший пути к элементам во вторичный файл как переменную, так что в теории можно было бы легчайше добавить новые пути к нему. Но большая часть авторов едва ли планировали наперед, что новые переделки UI вообще когда-нибудь появятся… а эти авторы исчезли годы и годы назад.  Некоторые такие моды имеют закрытые разрешения (closed permissions), так что создать патчи конкретно под них не представлялось возможным (плюс к тому Обливион включает свои скрипты прямо в файлы ESP, так что патчи совершенно выжгли бы все слоты порядки загрузки). Я ведь и в Обливион не часто играю, да и никогда не играл. Я взял копию на распродаже год назад и решил поиграть время от времени, отвлекаясь от событий в собственной жизни, помешавших работе над проектами для Скайрима. Так вот и получилось, что мне очень сильно не понравился UI Обливиона, и уж очень мне захотелось его адаптировать под нечто более привычное, что и вылилось в…это. Мой опыт игрока потребовал включения в игру наиболее популярные графические моды и парочку фиксов для стабильности, и понеслась. Те категории модов, которые вмешиваются в работу UI, это именно те категории модов, которые я, как ультра-казуальный игрок (да и, прямо скажем, не игрок вообще), никогда бы не нашел сам по себе, так что я был совершенно ошеломлен размахом несовместимостей. В итоге я в некоторых случаях отмодифицировал UI так, чтобы у модов, требовавших полного пути к элементам, был-таки доступ, но к невидимым элементам,созданным под них, а после UI бы копировал информацию из них и\или из этих фейковых элементов (dummy elements). В свою очередь это потребовало внимательно прочесть то, что, собственно, эти моды хотели. (Это было действительно тяжело, ведь я не привык к скриптовому языку Обливиона, и мое взаимодействие с ним редко было приятным: неудобно редактировать, неудобно компилировать, а компиляция часто выходит неправильной…). В других случаях было проще и чище просто взять концепцию мода и имплементировать её в NorthernUI самому, как часть его функционала. Никаких векторов, только растеризация, Финальная Точка UI Скайрима использует векторную графику по подобию фреймворка Scaleform, который позволяет запускать Adobe Flash прямо внутри игры, что важно. (Примерно половина читателей собирается сказать: «Ого, Беседка точно сделала бы что-то настолько кривое!» Но это касается не только их.) Из-за этого модифицирование UI становится очень недоступным, ведь тебе для модифицирования нужна конкретная версия конкретного софта, созданного конкретно под бизнес и с конкретным ценником для бизнеса, не говоря уже о том, что Scaleform перестали поддерживать пару лет назад. Но, как ни странно, есть одно преимущество: ты получишь все плюшки Adobe Flash, включая векторную графику, которую можно отображать великолепно сглаженными линиями при любом увеличении, а также использовать JavaScript, если нужно нечто подобное. Напротив, в Обливионе UI использует XML и текстуры DDS. Игра берет этот XML и рендерит элементы внутри себя в 3D, как серию динамически конструированных четырехугольников с нанесенными на них текстурами (quads with textures mapped to them). Это значит, что вся UI графика, включая шрифты, является игровыми текстурами, вот почему различные настройки графики игры влияют и на UI. Это значит, что и FOV, если изменен, полностью разрушает все подогнанные под друг друга элементы UI. Ну то есть, формат файлов для шрифтов Обливиона буквально определяет каждый глиф в размерах (size), выравнивании (alignment) и UV координатах текстуры. Для NorthernUI всё это привело к куче последствий, некоторые из которых были очень и очень непредсказуемыми. По ходу наистраннейшая проблема, с которой я столкнулся, если к курсору мыши в игре применяется какое-либо сглаживание текстур (что происходит по умолчанию), то каждая текстура пользовательского интерфейса, кроме курсора, в итоге окажется абсолютно испорченной. Представьте себе, что вы уменьшаете изображение вдвое, снова увеличиваете его с помощью ближайшего соседа (nearest-neighbor), а затем невероятно размываете его. Этой проблемы с оригинальным UI игры не обнаружить, поскольку скевоморфический (skeuomorphic) дизайн Бесезды действительно сильно не затрагивается этой проблемой, но, если ты создашь дизайн с чистыми, четкими линиями, всё пойдет по очень плохому сценарию. Пришлось хакнуть часть движка именно для того, чтобы исключить курсор из сглаживания текстур, так что теперь он рендерится с неровными линиями, но все остальное выглядит нормально. Всё, кроме этого, было лишь проблемами самого дизайна. Растровая графика четко не масштабируется, а поскольку Обливион адаптирует интерфейс к вашему соотношению сторон, интерфейс всегда будет масштабироваться немного больше, чем нужно. Формат шрифтов тоже масштабируется не очень хорошо. Теоретически, можно было создать текстуру шрифта сверхвысокой четкости и затем присвоить глифы маленьким четырехугольникам, позволив и маленьким шрифтам рендериться чётко и чисто даже при ультра-высоких разрешениях экрана. На практике что-то странное творится с UV, так что текстуры шрифтов не обрезываются правильным образом, и буквы искажаются. Если спросите, чего я больше всего хотел бы сделать, так всё просто: добавить в каком-либо виде поддержку векторной графики прямо в движок. Если можно было бы рендерить SVG и, возможно, настоящий формат шрифтов, то создание высококачественных UI при любом разрешении было бы намного проще реализовать, и тогда было бы намного проще предложить широкий выбор для таких вещей как масштабирование интерфейса и (в частности) размеров шрифтов, последнее было бы прекрасным параметром доступности (accessibility option). NorthernUI как он есть может быть и выглядит для вас хорошо, но, тем не менее,  я не могу не замечать, как рамка компаса (при настройках по умолчанию) заметно жирнее рамок здоровья\магии\усталости, поскольку отмасштабируй ты компас чуть меньше, и его рамка размажется к ядреной матери на большей части разрешений экрана. В один момент, когда я пытался понять, в чем проблема со сглаживанием текстур, я настолько отчаялся, что я взял, да и создал 3D модель элемента из Скайрима в Блендере, а именно элемент «вверх» в полосках прокрутки (scrollbars), то есть крышку. Обливион позволяет включить NIFы прямо в UI (это и позволяет запускать комплексные анимации, включая мини-игры взлома замков и колесо убеждения),  потому я и решился использовать эту возможность как легкий способ заменить «векторную графику». Но помните, что я сказал прежде: интерфейс рендерится с теми же настройками графики, которые установлены и для мира игры. (Из интерфейса также удаляется большая часть шейдеров при этом, но я легко остановил это безобразие патчем.) Крышка полоски прокрутки, которую я сделал, выглядела бы идеально сглаженным при высоком сглаживании, но, если правильно помню, Обливион использует MSAA, что очень нагружает компьютер. Без сглаживания этот элемент становился искаженным и совершенно непригодным к использованию. Позорище! Трехмерная крышка в NifSkope, с выделенной серой частью и видимыми краями многоугольника. В основном это был 3D-эквивалент трассировки, но, если не изменяет память, чтобы упростить работу я разрезал диск пополам, чтобы получить закругленное основание. Вот, как я говорил, я очень горд своей работой над растровой графикой. Я вычленил оригинальные SVG из интерфейса Скайрима как визуальный референс, но Бесезда не позволяет авторам портировать официальные ассеты между играми, так что у графики NorthernUI пикселизированные мной вручную элементы с помощью GIMP. Я перерисовал почти всё и очень горд полученным результатом. Первые попытки просто старались походить на Скайрим, но там было много нюансов в том, как устроены рамки и линии, на что я обратил внимание во вторую очередь. Я пишу это не для того, чтобы кичиться и хвастаться. Скорее речь идет об удаче в том, что удалось сделать так хорошо, смекаете? Я давно не работал с подобным типом пиксель арта, да и программирование мне намного ближе, так что весь полученный опыт с артом уже выветрился из головы. Исходное изображение угла блока слева при масштабе 200 % и текущее изображение угла блока справа при обычном масштабе. Обратите внимание на особенности линий справа, имитирующих оригинальную векторную графику в Skyrim. Исходное изображение компаса слева при масштабе 300% и текущее изображение компаса справа при обычном масштабе. Обратите внимание, что новая графика более соответствует образцу (on-model), как с точки зрения пропорций и углов, так и с точки зрения того, где узел перекрывается. Переделка ассетов в высоком разрешении была наилучшим решением, которое я только мог принять в работе над этим модом. Больше пикселей – больше пространства для работы, буквально. Это и помогло в том, чтобы получить правильные ракурсы и сохранить наименьшие детали. Помогло то, что мне не нужно было быть абсолютно точным. Если вы внимательно посмотрите на новую крышку компаса, вы, вероятно, увидите некоторые неровные края и некачественное сглаживание; поскольку Обливион всегда хотя бы немного масштабирует пользовательский интерфейс, «идеальное» сглаживание часто выглядит в игре хуже, а слишком грубые или резкие края будут размазаны ровно настолько, чтобы их сгладить. Это означает, что мне не нужно было имитировать до пикселя векторную графику Skyrim; этого было достаточно, чтобы на 90% соответствовать образцу. Горячие Клавиши Много людей просило поддержку горячих клавиш (hotkeys) на геймпадах Xbox, отчего ответ на это медленного сдвинулся от «надеюсь, что скоро» к «возможно, позже» и, наконец, к «скорее всего нет», если быть честным. Я углубился в некоторые проекты по Скайриму (пока пишу эти строки я делаю альтернативу Creation Kit, сделанную с нуля*) и я боюсь, что, отбросив эти проекты на слишком долгое время, я уже никогда к ним не вернусь. Я посматривал на систему горячих клавиш в Обливионе время от времени, но она выглядит…странноватой. Возможно, сейчас-то я выучился достаточно чтобы понимать всё это несколько более полно, но как я уже сказал – другие проекты! Из того, что я наблюдаю в комментариях, вы все сами нашли свои пути компенсировать это зияние в функциональности. Хотя бы так. Я могу по крайней мере объяснить кое-что из того, что знаю, чтобы легче было искать. Самое странное по теме горячих клавиш заключается в том, что Бесезда не хранит одну единственную вещь (заклинание) по ключу (store one single item per key). Под капотом они хранят список (list) предметов (или заклинаний) по ключу, но при этом они, как кажется, позаботились о том, чтобы список содержал только один предмет. Там еще около полдесятка полностью не-определенных переменных в движке, которые связаны с системой горячих клавиш, некоторые из которых, кажется, являются таймерами. Мое главное опасение касается того, что я не хочу даже пытаться имплементировать доступ к горячим клавишам на геймпаде, когда я едва понимаю как эта система работает на банальных клавиатуре и мыши. Я должен сперва понять, зачем Бесезда использует список, и что это за переменные, а времени копаться в этом глубоко у меня нет. * Это проект DovahKit, о котором с 2021 года ни слуху, ни духу. Но на сайте автора он до сих пор упоминается. – АrtSH. Что ж, это было всё на сегодня Надеюсь, это было интересно читать. Я знаю, что некоторым людям интересно подглядывать в щелочку, и я считаю правильным просто написать о таких вещам через какое-то время, так что они могут быть запомнены, а не забыты. Я никогда не ожидал того, что NorthernUI получит столько внимания. Как создатель контента, я «свой» в Скайриме, так что, когда я опубликовал NorthernUI, я считал Обливион мертвой игрой и никак не предполагал, что он сорвет трехзначное количество «одобрений». Вы меня убедили, что я не прав, за очень короткое время: те из вас, кто прилип к The Elder Scrolls IV, невероятно преданны этой игре. Я пытаюсь не отвечать на сообщения, если только они не содержат реквесты или чего-то подобного, поскольку я чувствую себя неловко, когда дело идет о похвале. Просто половина моих комментариев посвящена похвале мода и благодарности мне, и это выглядит нескромно. Однако я действительно читаю каждый комментарий, и меня впечатлило такое количество людей, которые до сих пор любят Обливион, и после всего этого времени говорят мне, как мой мод помог им вернуться к старой классике. Игры – не моя сцена, сказать по правде, но коль люди говорят, что я помог им вернуть ту самую магию, то это даже трудно осмыслить. Я рад, что даже при всех недостатках, NorthernUI смог помочь классической игре продолжать жить – и слегка модернизировать её для тех, кто этого хотел.

Детали о ремейке The Elder Scrolls IV: Oblivion рассказали в издании MP1st. Авторы ссылаются на одного из сотрудников студии Virtuos, которая занимается переизданием совместно с Bethesda. Ремейк Oblivion создают на движке Unreal Engine 5. Игру «полностью перерабатывают», что указывает на значительные изменения по сравнению с оригинальной версией. На сайте сотрудника были указаны краткие описания шести игровых систем, которые обновят: выносливость, скрытность, блокировка, стрельба из лука, реакции на удары и интерфейс (HUD). Иконки в HUD Как изменили механики Механику блокировки делают с учетом «soulslike» и «ACT», под которой, видимо, имеется в виду трилогию Assassin’s Creed. Механика из оригинальной названа слишком «монотонной» и «раздражающей». Стрельба из лука подтянута до современных стандартов с учетом игры от первого и третьего лица. Реакции врагов на удары переработали для лучшего отклика. Переработали методы расчета урона. Иконка стелса теперь будет ярче, чтобы игрок проще понимал в стелсе он или нет. Переработана механика усталости, чтобы исключить долгий стан и частое попадание в него. Принцип работы выносливости обновили, чтобы при её истощении персонажа не было так легко повалить в нокаут. Изменение направлено на то, чтобы снизить раздражение этой механикой у игроков. Интерфейс переработан в пользу упрощения и понятности для новых игроков.   Ранее три источника, включая инсайдера NateTheDrake, сообщили о выходе ремейка The Elder Scrolls IV: Oblivion в 2025 году.

Перевод инструкции для пользователя OBME - Oblivion Magic Extender. Инструкция расскажет об основах магической системы Обливиона, приведет  номенклатуру технических средств её реализации и объяснит, какие именно нововведения привнесены в эту систему модификацией. примечания переводчика Это инструкция, приложенная к OBME, в архиве с модификацией. Её перевода мне обнаружить не удалось. По сути документ представляет собой техническую номенклатуру эффектов магии в игре, описания способов её функционирования, а также нововведений в данную систему со стороны OBME. Вполне полезный документ для всех модеров, который поможет разобраться в магической системе с технической точки зрения. оглавление 1. Особенности Модификации 2. Обзор Магической Системы Обливиона 3. Параметры Эффектов 3.1 Коды Магического Эффекта 3.1.1 Динамические Коды Эффекта 3.2 Обработчик Эффекта 3.3 Основные Свойства 3.4 Аудиовизуальные Эффекты 3.5 Свойства Эффектов и Магических Объектов 3.6 Сопротивления и Счетчики 3.7 Создание Параметров Эффекта из Скрипта 4. Эффекты 4.1 Основные Поля 4.2 Поля Перезаписи 5. Сопротивления 6. Эффекты Присвоения 7. Враждебность 8. Обработчики Эффектов 8.1 ModifyActorValue 8.2 SummonActor 8.3 SummonBoundObject 8.4 ScriptEffect 8.5 Dispel 8.6 Cure 8.7 Shield 8.8 Absorb 8.9 Calm 8.10 Chameleon 8.11 CommandCreature 8.12 CommandHumanoid 8.13 Darkness 8.14 Demoralize 8.15 DetectLife 8.16 DisintegrateArmor 8.17 DisintegrateWeapon 8.18 Frenzy 8.19 Invisibility 8.20 Light 8.21 Lock 8.22 NightEye 8.23 Open 8.24 Paralysis 8.25 Reanimate 8.26 SoulTrap 8.27 SunDamage 8.28 Telekinesis 8.29 TurnUndead 8.30 Vampirism 1. Особенности модификации Больше возможностей контроля в редактировании Параметров Эффекта и Эффектов в CS. Возможность создавать новые Параметры Эффектов и в CS и внутри игры по скрипту. Расширение полей "Перезаписи" (Override) для Эффектов с целью кастомизации свойств, таких как Имя, Школа, Враждебность, Код VFX, Иконка, AV Сопротивления, Базовая Цена и другие. Эти перезаписи могут быть применены к любому эффекту (а не только к скриптовому). Расширение обработчика ModifyActorValue специфицирует какой именно модификатор задействован. Расширение обработчика  SummorActor позволит кастомные лимиты вызова акторов. Расширение обработчика ScriptEffect позволит использовать скрипты, указанные для всего магического эффекта, а не только для отдельных элементов эффекта. Расширение обработчика Dispel позволит частичное рассеивание эффектов и выборочное рассеивание, основанное на магическом эффекте, обработчике эффекта, враждебности и типе магического обьекта. Активные Эффекты, которые рассеиваются из-за рекаста заклинания или превышения лимитов вызова акторов, могут быть присвоены (reclaimed), то есть остававшаяся для них магия будет использована для усиления эффектов, которые их заменяют. 2. введение в магическую систему обливиона До моддинга с OBME лучше ознакомиться с основами магической системы Обливиона. Я бы предложил прочесть статьи по магии в TESCS Wiki. Все последующее лишь краткий обзор иерархии магических обьектов. Magic Item → Effect Item → Effect Setting → Active Effect → Effect Handler Магический Объект → Эффект → Параметр Эффекта → Активный Эффект → Обработчик Эффектов Магические Объекты – это Заклинания, Зачарования, Ингредиенты и Зелья. Конкретный тип и другие свойства, такие как цена и уровень мастерства, определяют, как и когда магический объект используется. Рассмотрим стартовое заклинание игрока «Исцеление Малых Ран»: поскольку это заклинание, его кастуют. Базовая цена каста – 14, то есть кастующий должен иметь уровень мастерства ученик в соответствующем навыке и 15 пунктов магии (при навыке в 25 пунктов). Каждый магический объект содержит список эффектов (Effect Items), ссылающийся на конкретный параметр эффекта и несколько параметров конкретного заклинания (магнитуда, продолжительность). «Исцеление Малых Ран» имеет только один эффект: «Восполнить Здоровье на 8 пунктов на себя». То есть, оно использует эффект «Восстановление Здоровья» и имеет магнитуду в 8 пунктов. Параметры Эффектов (Effect Settings), таких как «Урон Огнем», «Призыв Скелета» или уже упомянутый «Восстановление Здоровья». Параметр эффекта содержит набор параметров таких как имя, цена или визуальный эффект, определяющий уникальный магический эффект. И действительно, «Параметр Эффекта» и «Магический Эффект» часто взаимозаменяемые понятия. Когда заклинание или другой магический объект используется по цели, он создает набор Активных Эффектов. Каждый активный эффект соответствует эффекту из магического обьекта и хранит параметры по каждой конкретной цели (такие как, оставшееся время действия, окончательная магнитуда действия). Кастуя «Исцеление Малых Ран», к примеру, игрок создает новый активный эффект на самом себе с магнитудой 6 пунктов, если у игрока есть эффективность заклинаний в 75%. Когда Активный Эффект создан, он как раз и создает «магию», используя Обработчик Эффектов (Effect Handler). К примеру, для «Исцеления Малых Ран», используется обработчик эффектов «Изменение Параметра Актора» (Modify Actor Value). Этот обработчик поднимает или опускает параметры актора у конкретной цели. Параметры, содержащиеся в параметре эффекта «Восстановление Здоровья», предписывают обработчику поднять параметр Здоровья цели. Параметры, содержащиеся в эффекте и активном эффекте, предписывают обработчику поднять параметр сразу же на 6 пунктов. 3. параметры эффектов Параметры Эффектов – то, что люди зовут «Магическим Эффектом» в Обливионе. Параметр эффекта содержит много параметров, которые сообща определяют уникальную часть магии. Они могут быть созданы, удалены и изменены с помощью CS диалогового окна «Магические Эффекты». Они скорее всего знакомы всем, даже игрокам, которые не сделали ни единого мода, потому что они перечислены в меню создания заклинаний и зачарований. 3.1 Код Магического Эффекта Отличие от большинства обьектов  в Обливионе, параметры эффекта не идентифицируются по formID. Вместо этого у них есть свой собственный набор «Кодов Магического Эффекта» (mgefCodes). Эти коды используются всякий раз, когда игре нужно сослаться на конкретный магический эффект. Измени код эффекта, и это сломает всё, что на него ссылается, так что лучше никогда не менять код эффекта в параметрах эффекта после его создания. Если так всё же надо сделать, OBME позволит это только для параметров эффекта, добавленных активным файлом. Если два мода добавляют два разных параметров эффекта (Effect Settings) с тем же самым кодом эффекта, один перезапишет другой. Чтобы этого избежать моддеры должны убедиться, что их коды эффекта совершенно уникальны среди всех модов. Это точно сомнительно, ведь существует 4 миллиарда возможных кодов в конце-то концов, но для казуальных моддеров это боль. 3.1.1 Динамические Коды Эффекта Чтобы избежать такой возможности конфликта со статичными кодами эффекта, ОБМЕ может автоматически присвоить «Динамический Код Эффекта».  Динамические коды эффекта работают через ОБМЕ тем же путем, каким formID управляются игрой и CS, то есть они меняются в зависимости от того, в каком месте находится мод в нынешнем порядке загрузки (load order). Поэтому эффекты с динамическими кодами не будут (ненамеренно) конфликтовать с другими модами. Но есть нюанс. Начиная с 10 версии ОБСе или около того, ОБСЕ позволил модерам зранить и использовать коды эффектов в скриптовых переменных. ОБМЕ не может их исправить так, как он исправляет хранящиеся коды эффектов, поскольку он не знает какая переменная их хранит. Короче говоря, Динамические Коды Эффектов могут сломать некоторые существующие скрипты. Подобные крипты должны быть довольно редки, но всё же, я вас предупреждал. Вы точно можете написать новый скрипт, который будет вполне себе обрабатываться динамическими кодами эффектов. Главное не хранить код эффекта в переменной между фреймами. К примеру, представьте скрипт, который берет первый эффект конкретного заклинания и использует его в другом блоке: Вместо хранения кода, получим его прямо: Иначе можно использовать новую скриптовую функцию ResolveMgefCode, добавленную ОБМЕ. Эта функция может быть вызвана единожды после загрузки сохранения чтобы «разрешить» хранящийся код эффекта: 3.2 Обработчик Эффектов Параметры эффектов должны специфицировать какой именно Обработчик Эффектов они используют. В дополнение к самому обработчику параметр эффекта может иметь несколько спец-параметров для обработчика и флагов (таких как formID скрипта, вызванный обьект, параметр актора). За подробностями обращайтесь к Обработчикам Эффектов. ОБМЕ представляет новые скриптовые функции чтобы получить\присвоить обработчик эффектов и его параметры данному магическому эффекту: Обработчики определены их «Кодом Обработчика». Коды обработчиков и валидные параметры имен прописаны в секции Обработчиков Эффектов. Заметьте, что ОБСЕ имеет похожие функции: Эти функции продолжат работать так, как и запланировано, но лучше использовать новые функции из ОБМЕ. 3.3. Основные Свойства А дальше текст. Все содержимое этого блока вы можете переписывать по своему усмотрению. Name Отражаемое имя магического эффекта. Некоторые эффекты (Fortify, Drain, другие) могут "специфицированны" дополнительным текстом. FormID Параметры эффекта технически являются формами и могут получать formID. Однако, они совершенно игнорируются игрой. Вместо этого параметры эффектов идентифицируются по их Коду Магического Эффекта. EditorID Эта строка (string) используется для идентификации эффекта в CS во многом по той же схеме, по которой editorID используется другими обьектами. Конкретно множество скриптовых функций, который усваивают char магического эффекта, на деле ожидают editorID (или референс). Icon Отображаемая иконка эффекта. Base Cost Множитель (Multiplier) стоимости магии эффекта для использования этого эффекта. School Какой школе магии принадлежит эффект. Hostility Враждебность эффекта. Пройдите в секцию Враждебность за подробностями по возможным значениям. Это свойство может быть установлено внутри игры, используя новые команды OBME GetMagicEffectHostilityC и SetMagicEffectHostilityC. Эти функции созданы чтобы заменить команды OBSE Is(Set)MagicEffectHostile(C). Команды OBSE продолжат функционировать, но они не различают состояния "Нейтральный" и "Положительный" (Beneficial). Effects Removed Он же "Recovers". Для каждого обработчика эффектов, который его поддерживает (а это могут не все), этот флаг обозначает, что всё, что делает эффект, когда применяется по цели, отменяется, когда эффект исчезает. Remove On Death  Эффект автоматически удаляется при смерти цели. Explodes with Force  Взрыв использует игровую физику и может двигать физические обьекты (предметы инвентаря, трупы)   3.4. Аудио и визуальные эффекты   Cast Sound Звук, создаваемый анимацией каста (заклинания). Bolt Sound Звук, создаваемый движением проджектайла. Hit Sound Звук, создаваемый в момент приложения эффекта к цели. Area Sound Неизвестно. Model Файл .nif, содержащий 3D эффекты для каста, движения проджектайла, целей и зоны действия эффекта. Hit Shader Он же "Effect Shader". Шейдер Эффекта используется по цели, когда эффект применяется к ней. VFX Shader Шейдер Эффекта зацикливается на цели пока эффект не рассеивается (то есть в данном случае визуальный эффект длится, а не срабатывает один раз). No Effects On Hit Нет звука, 3D эффекта или шейдера при применении к цели. Projectile Type Форма магического проджектайла. Большая часть эффектов использует "Шар", но "Урон Шоком" использует "Болт" (Bolt), а "Урон Морозом" использует "Туман". Также доступен четвертый тип, "Спрей". Тестирование предполагает, что файл модели (Model file) должен содержать соответствующую информацию для выбранного типа проджектайла. Projectile Sound Скорость, с которой путешествует проджектайл (множится с помощью fMagicProjectileBaseSpeed).   3.5. свойства эффектов и магических объектов Use in Alchemy Эффект доступен для зелий и ингредиентов. Use in Spells Эффект доступен для Алтарь Создания Заклинаний. Этот флаг игнорируется при создании заклинаний в CS. USe in Enchantments Эффект дсотупен для Алтаря Зачарований. Этот флаг игнорируется при создании зачарований в CS. Enchant Factor Скалирует магнитуду эффекта на зачарованиях Брони. Barter Factor Скалирует стоимость зачарованного предмета. Has a Magnitude Эффект использует магнитуду Эффектов (Effect Items). Has a Duration Эффект использует продолжительность Эффектов. Эффекты с мгновенным действием неразрешены на постоянных магических обьектах, таких как Болезни. Has a Area Эффект использует Область Эффектов. Заметьте, что этот флаг всегда игнорируется на эффект "На Себя", независимости от того, активирован этот флаг или нет. Has OnSelf Range Может ли Эффект иметь тип "На Себя". Некоторые магические обьекты (Способности (Abilities) и Болезни) используют эффекты только подобного типа. Has OnTouch Range Может ли Эффект иметь тип "При Касании". Некоторые магические обьекты (Зачарования Оружия) используют эффекты только подобного типа. Has OnTarget Range Может ли Эффект иметь тип "На Цель". Некоторые магические обьекты (Зачарования Посоха) используют эффекты только подобного типа.   3.6. Сопротивление и счетчики Resistance AV Параметр Актора, который снижает продолжительность или магнитуду эффекта, когда тот применяется к цели. Counter Effects Список эффектов, который может отменить или ослабить этот эффект. Этот список не имеет прямого магического воздействия, но используется системой ИИ для выора соответствующего противо-заклинания, противоядия, зелья и т.д.   3.7. Создание параметров эффекта из скрипта Новые параметры эффектов могут создаваться в игре, использу скриптовую функцию CreateMgef, добавленную OBME: Первый аргумент может специфицировать уникальный статический код эффекта или же, получая значение 0, запросить динамический код эффекта. Второй аргумент опционален и специфицирует код эффекта у существующего эффекта чтобы его дублировать. Возвращаемое значение вернет значение кода эффекта от нового эффекта или будет равно нулю при ошибке. Эффекты созданные этой функцией сохраняются в слот сохранения игры точно так же, как созданные игроком зелья и заклинания. Эта функция аналогична CloneForm, добавленной OBSE, и имеет те же проблемы с раздуванием сохранений (savegame bloat). В общем и целом, создав новый эффект, вы его уже никогда не уничтожите - используйте эту функцию с умом. 4. Эффекты 4.1 Основные Поля   Magic Effect Параметр Эффекта для использования. Magnitude Базовая магнитуда эффекта (до штрафов, сопротивлений и прочего). Использует союственный обработчик, за подробностями обращайтесь к секции индивидуальных обработчиков. Duration Базовая продолжительность эффекта в секунду. Эффект с нулевой продолжительностью применяется только к одному фрейму. Это поле игнорируется эффектами без флага "Has Duration" (такие эффекты всегда имет нулевую продолжительность). Также игнорируется эффектами "постоянных" магических обьектов, таких как Болезни (они никогда не прекращаются). Area Радиус, в футах. Когда магический обьект кастуется, каждая подходящая цель в заданном радиусе затрагивается эффектом. Это поле игнорируется теми магическими обьектами, которые нельзя кастовать (Ингредиенты, Способности, т.п.). Также игнорируется эффектами с диапазоном типа OnSelf и эффектами без флага "Has Area". Range OnSelf OnTouch OnTarget Эффект применяется к кастующему\пьющему зелье\экипирующему предмет. У некоторых магических обьектов (таких как Зелья) этот диапазон единственный. Эффект применяетсяпо цели при физическом контакте. . У некоторых магических обьектов (таких как Зачарованное Оружие) этот диапазон единственный. Эффект обьединяется с другими в проджектайл, который может попасть или не попасть по цели. У некоторых магических обьектов (таких как Зачарования Посохов) этот диапазон единственный. Используя заклинание, свиток и т.д., вы создадите один проджектайл, который содержит все эффекты типа OnTarget. Handler-Specific Field Дополнительное поле на каждый эффект для специального использования. Оно используется только одним оригинальным обработчиком, ModifyActorValue, для хранения кода параметра актора (an actor value code). 4.2 Поля Перезаписи В дополонение основным полям Эффекты могут иметь дополнительные поля "перезаписи". Если они включены, эти значения будут использованы вместо соответствующих значений из перезаписываемых параметров эффекта. К примеру, создав эффект "Урон Огнем" и установив параметр Враждебность во вкладке "перезаписи" на "Нейтральный", вы получите не реагирующих негативно на игрока акторов, если он бьет их этим эффектом. Эти поля используются оригинальной игрой по отношению к секциям Name, School, Hostility и визуальным эффектам чтобы поддерживать скриптовые эффекты (SEFF). Заметьте, что с OBME каждое поле должно быть "включено" индивидуально чтобы перезаписать оригинальное значение. Отключенные поля перезаписи тоже могут иметь значение, но оно будет полностью проигнорированно игрой. В CS поле перезаписи отмечено серым, если отключено. Effect Name  Заменяет базовое название эффекта ("Урон Огнем" или "Укрепление Атрибута").  Base Cost Заменяет базовую цену для исчисления количества магии.  School Заменяет магическую школу для проверок навыков (skill checks).  Hostility Заменяет враждебность, которая влияет на враждебность магического объекта целиком. За подробностями обращайтесь к секции Враждебность по возможным параметрам.  Icon Заменяет иконку, показываемую в инвентаре и интерфейсе.  Effects Removed Заменяет флаг параметра "Эффект Удален".  Resistance AV Заменяет эффект сопротивления.  VFX Code Не соответствует прямо ни одному свойству параметров эффекта. Вместо этого это поле специфицирует другие параметры эффекта, из которых копируется всё, что относится к аудио-визуальной составляющей.  Handler-Specific Fields Дополнительные информация и флаги, связанные с конкретным обработчиком. За подробностями обращайтесь к секции индивидуальных обработчиков. Из оригинальных обработчиков эффектов только ScriptEffect использует эти поля.   OBME представляет ряд новых скриптовых функций для манипулирования этими полями перезаписи. Функция Get возвращает актуальное значение поля перезаписи, если то включено, или возвращает значение соответствующего поля из параметра эффекта. Другими словами Get всегда возвращает актуальное значение, используемое игрой. Функция  Set устанавливает актуальное значение для поля перезаписи и включает его, если оно было отключено. Функция Clear отключает поле перезаписи чтобы игра игнорировала значения этого поля. Валидные параметры имен для Get/SetNthEIHandlerParam перечислены в секции Обработчики Эффектов. Заметьте, что OBSE вводит похожий функционал: Эти функции продолжат функционировать в оригинальном Скриптовом Эффекте ("Script Effect"), но работать как перезапись для других эффектов (effect items) не будет. Более конкретно, эти функции не будут работать, если поле перезаписи уже включено, но включить или выключить его сами по себе они не могут. 5. Сопротивления Самое главное запомните, что сопротивления не применяются к эффектам с диапазоном "на себя" или к эффектам не-враждебных магических обьектов. Это включает в себя: все способности, зачарования одежду, ингредиенты, зелья все эффекты заклинаний с диапазоном "На Себя", свитков, сил и посохов любой магический объект с не-враждебными эффектами Болезни немного другие: Сопротивление Болезням затрагивает шанс игрока подхватить болезнь, но, будучи подхваченной игроком, болезнь тут же игрорирует все сопротивления. Для магических обьектов, соответствующих критериям, существуют два уровня сопротивления магии. Первый относится к сопротивлению Магических Обьектов, и он модифицирует силу каждого эффекта у обьекта. Для оригинальной игры это заклинания, силы и зачарования типа "Сопротивление Магии" и Сопротивление Яду для зелий. Сопротивление Болезням, как уже сказано, немного особенное. Второй уровень является сопротивлением Магических Эффектов, и он модфицирует силу отдельных эффектов. Параметр актора (AV) использует свойство "Сопротивление AV" из параметров эффекта или самого эффекта. Если два уровня сопротивления используют разные параметры актора, к примеру, Сопротивление Магии Сопротивление Огню, тогда формула общего сопротивления будет следующей: Если оба уровня используют тот же параметр актора, к примеру, оба используют Сопротивление Магии, тогда формула будет проще: Этот фактор множит базовую продолжительность (или магнитуду для мгновенных эффектов). Слабости имплементированы в игру как негативные сопротивления и используют ровно те же две формулы. Отражение Заклинаний и Поглощение применяются до проверки сопротивляемости. Как только отраженное заклинание возвращается кастующему, оно начинает подчиняться всем сопротивлениям как и любое другое заклинание. Наконец, для заклинаний со свойством "Скриптовый Эффект Всегда Применим" (Script Effect Always Applies), скриптовые эффекты имеют полный иммунитет к отражению, поглощению и всем сопротивлениям. 6. Эффекты присвоения Большая часть магических объектов, в частности заклинания, могут применяться только по цели. Если они применяются повторно, то первоначальные эффекты отменяются. OBME добавляет механику "присвоения" оставшейся магии и использует её чтобы усилить новые примененные эффекты. К примеру, предположим игрок кастуем заклинание "Облегченное Бремя", которое имеет единственный эффект "Пёрышко 75 пунктов на 300 секунд на себя" и имеет базовую цену в 75 пунктов магии. После 200 секунд у эффекта остается еще треть от его продолжительности, так что он "стоит" уже около 25 пунктов магии. Если игрок сейчас перекастует это заклинание, вся эта оставшаяся магия будет потеряна. Но с присвоением некоторая часть магии применяется к новому эффекту, скажем, 80%, а значит около 20 пунктов магии. Тогда новый эффект "Пёрышко" будет стоить 95 пунктов магии вместо 75 и поэтому будет длиться уже 380 секунд вместо 300. Фракция присвоенной магии контролируется новым параметром игры fMagicReclaimFactor. Если возможно, эффекты усиляются, удлинняя их продолжительность. Мгновенные эффекты или эффекты постоянных магических объектов (таких как Болезни) получают усиление собственной магнитуды. Присвоение также применино к эффектам Вызова (Summon effects), которые уничтожаются при выходе за пределы лимитов призыва. 7. враждебность OBME привносит новое состояние Враждебности для параметра эффектов, магических объектов и индивидуальных эффектов - "Положительное" (Beneficial). Это переработка старой схемы "Враждебное\Негативное". Как правило, враждебные эффекты ("Урон Огнем") это те, что применяются по врагу. Нейтральные эффекты ("Рассеивание") это те, что могут быть использованы по кому угодно, в зависимости от обстоятельств. По умолчанию магический обьект рассматривается как Враждебный, если имеет по крайней мере один враждебный эффект. Зелья печально известное исключение. Зелья будет рассматриваться как враждебное (и становится ядом) только если все его эффекты враждебны. Магический объект становится Положительным, если он не имеет враждебных эффектов и имеет по крайней мере один положительный эффект. Магические объекты с одними только нейтральными эффектами или вообще без эффектов рассматриваются как нейтральные. Для ИИ существует только разделение на Нейтральные\Положительные. Вражеские маги будут всегда использовать враждебные заклинания по боевым целям, а любой актор, получивший урон от враждебного заклинания, будет считать это нападением. Однако все три состояния используются некоторыми обработчиками эффектов (а именно Рассеивание (Dispel)). Для новых скриптовых функций, берущих и возвращающих три состояния враждебности, нумерические коды таковы: Neutral 1 Hostile 2 Beneficial 4 8. обработчики эффектов Обработчики Эффектов - фундаментальные блоки, из которых созидается магия Обливиона. Они являются кусками игрового кода, который и творит всю "магию", то есть повышает здоровье цели, делает их невидимыми, вызывает существо для кастующего. В оригинальной игре присутствуют 31 обработчик эффектов. Наиболее важными являются ’ModifyActorValue’, ’SummonActor’ или ’SummonBoundObject’ - эти трое обработчика используются для имплементации 75% оригинальных магических эффектов. Большая часть оставшихся обработчиков используется лишь одним магическим эффектом на каждый. Подробности, данные ниже, взяты из персональных тестов и разбора кода. Дополнительные описания и подробности по обработчикам, которые связаны только с одним единственным магическим эффектом, могут быть найдены на UESP Wiki. 8.1. Modify Actor Value ehCode   ’MDAV’ = 0x5641444D Description Модифицирует Параметр Актора (ActorValue ) у цели. Magnitude Определяет насколько поменять то или иное значение параметра. Если флаг "Effects Removed" не установлен и эффект имеет ненулевую продолжительность, то это значение этого поля определяет продолжительность в секундах. Actor Value Range (Для Параметров Эффекта) Пара Параметров Актора специфицирует диапазон. Актуальный AV для модификации выбирается из этого диапазона для каждого эффекта. "По умолчанию" AV устанавливает нижний порог диапазона и "Второй" AV устанавливает верхний порог. Параметр второго AV, установленный на "Нет" (None), обозначает, что все эффекты (effect items) должны использовать параметр "По Умолчанию". ParamName для скриптов: DefaultAV, SecondAV Actor Value (Для Эффектов) AV, который нужно изменить. Выбирается из диапазона подходящих значений, определенных родителем Параметра Эффекта. ParamName для скриптов: ActorValue - Заметьте, что эттот параметр не может быть отключен\очищен (disabled/cleared) тем же образом, что и другие параметры обработчиков. AV Part Часть\модификатор, подвергающийся изменению. За обьяснением различных частей (various parts) обращайтесь к TESCS Wiki по Параметрам Актора. Держите в уме, что с OBME часть AV выбирается вручную в этом поле, а не автоматически в зависисости от флага "Effects Removed" в оригинальной игре. ParamName для скриптов: AVPart Flags: Special treatement for Abilities Lowers AV Effects Removed В оригинальном Обливионе восстанавливаемые эффекты из заклинаний, подобным Способностям, на игроке всегда применяются к "Базовому" модификатору, а не к "Максимуму". Этот флаг воспроизводит данное поведение. Если не выбран, тогда эффект способности на игре не будет особенным образом обрабатываться. ParamName для скриптов: AbilitySpecial (Он же "Вредный" (Detrimental)) снижает значение, обратное увеличению значения ParamName для скриптов: ActorValue Изменение инверсируется, когда эффект исчезает  Deprecated Flags: UseSkill/UseAttribute UseAV Изначально для эффектов, которые используют диапазон возможных значений, по типу "Укрепление Атрибутов" или "Расход Навыка". Эти флаги сейчас игнорируются в CS. Но с беты3 версии 1 они еще определяют, какие AV доступны для алтарей зачарования и заклинаний. Изначально для эффектов, которые используют только один AV. 8.2 SummonActor ehCode   ’SMAC’ = 0x43414D53  Description Создает копию существа или НИПа рядом с целью и устанавливает дружественность его ИИ.  Magnitude Неиспользуется  Summoned Actor FormID актора, которого вызывают, или списка Уровневого Существа, из которого выбирается вызванный актор. Заметьте, что вызванный акторы обычно имет флаги  "Summonable" и "No Low Level Processing".  ParamName для скриптов: Summon (только для Параметров Эффектов)  Summon Limit FormID глобальной переменной, содержащей лимит вызова. Любые эффекты, которые связаны с вызовом, зависят от этого конкретного лимита. К примеру, скажем, оба "Призыв Скелета" и "Призыв Зомби" зависят от глобальной переменной SummonUndeadLimit со значением 3. Тогда кастующий может вызвать до 3 склетов\зомби одновременно в дополнении к тем призывам, которые используют другие лимиты. Это условие применимо только к эффектам из разных заклинаний. Рекаст того же "Призыва Скелета" три раза подряд даст только одного скелета. ParamName для скриптов: SummonLimit (только для Параметров Эффектов)  Flags: Use iMaxPlayerSum- monedCreatures Использует игровой параметр  iMaxPlayerSummonedCreatures как лимит вызова вместо глобальной переменной. ParamName для скриптов: UseVanillaLimit (только для Параметров Эффектов)  Deprecated Flags: UseActor (Он же UseCreature) Изначально использовался для различения SummonActor  от других обработчиков параметров. 8.3 SummonBoundObject  ehCode  ’SMBO’ = 0x4F424D53  Description Добавляет копию предмета инвентаря в инвентарь цели.  Magnitude Неиспользуется  Summon Object FormID предмета, который необходимо добавить ParamName для скриптов: Summon (только для Параметров Эффектов)  Deprecated Flags: UseWeapon Изначально использовалось для различения SummomBoundObject от других обработчиков эффектов. 8.4 ScriptEffect  ehCode  ’SEFF’ = 0x46464553  Description Запускает скрипт, когда эффект применяется или удаляется, и этот скрипт работает каждый фрейм пока он активен. За подробностями пройдите на страничку ScriptEffect TESCS Wiki.  Magnitude Не используется по умолчанию, но может использоваться скриптом.  Script FormID скрипта MagicEffect для работы с ним. Значение по умолчанию может быть специфицировано для параметроф эффекта, а индивидуальные эффекты могут перезаписать его их собственными скриптами. ParamName для скриптов: Script  User Parameter:   User Parameter UserParam Is FormID UserParam is MgefCode   Поле efitParam может использоваться чтобы хранить катомную информацию для скрипта или для другх модов. Этот параметр не добавлен OBME, а сохраняется и загружается оригинальной игрой и CS. OBME просто позволяет моддерам и авторам скриптов прямо его редактировать. ParamName для скриптов: UserParam (только для Эффектов) Пользовательский параметр должен загружаться и сохраняться как formID. Это позволяет моддерам хранить formID в этом поле без того чтобы вручную корректировать изменения в порядке загрузки. ParamName для скриптов: UserParamIsFormID Пользовательский параметр должен загружаться и сохраняться как код эффекта. Это позволяет моддерам хранить код эффекта в этом поле без того чтобы вручную корректировать изменения в порядке загрузки. ParamName для скриптов: UserParamIsMgefCode 8.5 Dispel  ehCode  ’DSPL’ = 0x4C505344  Description Убирает или ослабляет активные магические эффекту на цели.  Magnitude Усиляет эффект Рассеивания. Умножается переменной fMagicDispelMagnitudeMult чтобы дать эквивалентное количество магии, которая была рассеяна.  Effect Setting / EffectHandler Код эффекта (рассеять какой-то конкретный магический эффект) или код обработчика (рассеять эффекты, используя какой-то конкретный обработчик эффектов). Если код не определен, тогда все эффекты будут рассеяны в равной степени. Параметры для скриптов: mgefCode & ehCode - использование одного исключает использование другого.  Magic Item Type Рассеивает эффекты только из выбранных типов магических объектов Параметры для скриптов: DispelSpell, DispelDisease, DispelPower, DispelLesserPower, DispelAbility, DispelScrollEnchantment, DispelStaffEnchantment, DispelWeaponEnchantment, DispelApparelEnchantment, DispelAlchemyItem, & DispelIngredient  Hostility "Положительный" эффект рассеивания рассеивает только "враждебные" эффекты (или магические обьекты, если выбран пункт Treate Magic Items Atomically) "Враждебный" эффект рассеивания рассеивает только "положительные" эффекты (или магические обьекты, если выбран пункт Treate Magic Items Atomically) "Нейтральный" эффект рассеивания рассеивает все эффекты  Flags: Treat Magic Items Atomically No Partial Dispel Distribute Magnitude   Рассеивает все магические объекты, а не отдельные эффекты. Либо все эффекты объекта рассеиваются, либо никакие. Параметры для скриптов: AtomicMagicItem Эффекты либо убираются полностью, либо оставляются в покое. Если этот пункт не определен, тогда эффекты, которые слишком сильны чтобы их убрать, будут лишь ослаблены. Если используется с пунктом Treate Magic Items Atomically, рассеивание либо уберет полностью магический обьект или полностью оставит его в покое. Параметры для скриптов: AtomicDispel Каждый расеиваемый эффект получает фракцию от общей магнитуды рассеивания. Если этот пункт не определен, тогда каждый рассеянный эффект получает всю магнитуду рассеивания. Если используется вместе с пунктом Treate Magic Items Atomically, каждый магический обьект получает фракцию всей магнитуды рассеивания. Параметры для скриптов: DistributeMagicka 8.6 Cure ehCode   ’CURE’ = 0x45525543  Description Убирает специфический тип эффекта - болезни, яды и паралич.  HardCoded Этот обработчик закодирован функционировать только с оригинальными эффектами "Исцеление Болезней", "Исцеление Отравления" и "Исцеление Паралича".  Deprecated Новые Эффекты в этом смысле должны использовать расширенный OBME обработчик Dispel. 8.7 Shield  ehCode  ’SHLD’ = 0x444C4853  HardCoded Этот обработчик закодирован функционировать только оригинальные эффекты "Щит", "Огненный Щит", "Морозный Щит" и "Шоковый Щит". Он может частично работать для новых эффектов, но это не протестировано.  No details on this handler yet   8.8 Absorb  ehCode  ’ABSB’ = 0x42534241  No details on this handler yet   8.9 Calm  ehCode  ’CALM’ = 0x4D4C4143   No details on this handler yet   8.10 Chameleon  ehCode  ’CHML’ = 0x4C4D4843   No details on this handler yet   8.11 CommandCreature  ehCode ’COCR’ = 0x52434F43   No details on this handler yet   8.12 CommandHumanoid  ehCode  ’COHU’ = 0x55484F43  No details on this handler yet   8.13 Darkness  ehCode  ’DARK’ = 0x4B524144  No details on this handler yet   8.14 Demoralize  ehCode  ’DEMO’ = 0x4F4D4544  No details on this handler yet   8.15 DetectLife  ehCode  ’DTCT’ = 0x54435444  No details on this handler yet   8.16 DisintegrateArmor  ehCode ’DIAR’ = 0x52414944   No details on this handler yet   8.17 DisintegrateWeapon  ehCode  ’DIWE’ = 0x45574944  No details on this handler yet   8.18 Frenzy  ehCode  ’FRNZ’ = 0x5A4E5246   No details on this handler yet   8.19 Invisibility  ehCode  ’INVI’ = 0x49564E49  No details on this handler yet   8.20 Light  ehCode ’LGHT’ = 0x5448474C   No details on this handler yet   8.21 Lock  ehCode ’LOCK’ = 0x4B434F4C   No details on this handler yet   8.22 NightEye  ehCode  ’NEYE’ = 0x4559454E   No details on this handler yet   8.23 Open  ehCode ’OPEN’ = 0x4E45504F   No details on this handler yet   8.24 Paralysis  ehCode  ’PARA’ = 0x41524150  No details on this handler yet   8.25 Reanimate  ehCode ’REAN’ = 0x4E414552   No details on this handler yet   8.26 SoulTrap  ehCode ’STRP’ = 0x50525453   No details on this handler yet   8.27 SunDamage  ehCode ’SUDG’ = 0x47445553   No details on this handler yet   8.28 Telekinesis  ehCode ’TELE’ = 0x454C4554   No details on this handler yet   8.29 TurnUndead  ehCode ’TURN’ = 0x4E525554   No details on this handler yet   8.30 Vampirism  ehCode ’VAMP’ = 0x504D4156   No details on this handler yet  

Я играю и бросаю играть в Обливион уже лет десять, и всё то время, когда он стоит на моем ПК, у игры всегда наблюдаются проблемы, занимающие мой ум. Например, почему Западные Врата Чейдинхола так лагают? Я уверен, что и у вас не наблюдалось строгих 60 FPS в этой игре. Я ожидаю просадок, но даже в оригинальной игре я получаю только 30 FPS при i5 4690K при 4.4GHz и RX 570. Ладно, я тут пока писал стратью погонял с DXVK HUD и сравнил с Gallium HUD и, снова переключившись на DXVK, я заметил, что оптимизация улучшилась в разы. Переключился на Gallium HUD и снова получил хороший результат. Причина этого поста, по ходу, улетучилась, но может быть, имеет смысл для вашего игрового сетапа. Фреймрейт, который вы увидите, не стоит воспринимать как данность. Не знаю, что я сделал, починив этот косяк разработчиков. Но это все еще интересная проблема. Проблема Чейдинхола: низкий фреймрейт! Это старая игра, а наше железо уже в тыыыыщу раз круче того, что было в те годы. AnandTech использовал Athlon 64 dual core и SLI/Crossfire GPUs (который скалировался очень хорошо, Oblivion хорошо с ним ладит), и было верхом успеха получить 30 FPS при средних настройках в виде 1024x768. Сейчас у нас GPU и CPU за $200, разгоняющие современные игры до 100FPS при 1080p, но в Oblivion мы все также пытаемся вытянуть из фреймрейта 60FPS. Что за ерунда? Это большая тема, в которыю я сейчас не хочу погружаться. Поэтому обьясню проблему вкратце простыми словами, опираясь на свои наблюдения. Использование системы обливионом Обливион - плоть от плоти эпохи гейминга на DirectX 9. Он использует движок GameBryo, дополненный после Морровинда пачкой нововведений. Для нас в данном случае важны следующие: физика от Havok, уровень детализации на расстоянии (LOD) и динамическое освещение. Radiant AI тоже был таким нововведением, хотя по факту это улучшение того, что мы уже видели в Морровинде. Использование GPU Оригинальная игра, даже с модами, едва ли использует GPU. Единственные эффекты, которые действительно нагружают GPU, это вещи по типу шейдеров из ENB или Oblivion Reloaded. Большая часть рендерящихся эффектов, как рефракция или отражения в воде, привязаны к GPU. Современные GPU даже не заметят этой нагрузки, поэтому наши GPU всегда используются не на 100%. Использование CPU Будучи игрой из 2006 года, она не любит многопоточность. Большая часть вещей (вызовы отрисовки и ИИ – самые нагружающие) находятся в главном потоке CPU, когда как 1 и, возможно, дополнительный поток делают что-то еще (OSR, кажется, что-то делает с третьим потоком, но этого я еще не тестировал). Пусть ИИ действительно тяжел для загрузки, но в той зоне Чейдинхола лишь 2 стражника у Западных Ворот, так что их ИИ – просто погрешность. Вокруг нет ничего, что затрагивало бы физику. Динамическое освещение, отрисовываемое CPU, отсутствует. Едва ли есть ЛОДы в этой ячейке Чейдинхола, да и оригинальная игра не то чтобы много их в себе содержит. И если ЛОДы не проблема, то тогда откуда такая нагрузка? draw calls Вы скорее всего уже слышали такой термин и возможно в курсе, что «чем их больше, тем ниже оптимизация», но что по сути из себя представляет вызов отрисовки (draw call)? GPU, особенно старые, довольно тупые. Они просто берут информацию и рендерят её на экране. Сейчас GPU стали очень комплексными и способными делать множество вещей, которые выпадали на долю CPU в играх, но в 2006 это была мечта! Сама концепция шейдеров тогда еще была меньше десяти лет от роду. Так как вообще рендерят обьект? Откуда инфа о нем приходит? CPU говорит GPU что, где и как отрендерить. Самый важный аспект из представленных это ЧТО мы будем рендерить, так как он самый ограничивающий. В нашем контексте, я опишу весь меш обьекта как модель, а весь маппинг текстуры (texture mapping) как текстурную карту (texture map). Отдельные компоненты – это меши и текстуры. Сингулярный обьект, ну скажем, модель персонажа, это не единый меш с единой текстурой, привязанной к нему. Это комплексная модель, разделенная на части, позволяющая тем самым легко текстурировать и модифицировать эту модель. То есть вы разделяете модель персонажа на три меша с двумя текстурами на каждый (цвет и карта нормалей (normal map)). Затык в том, что CPU не знает, что это один обьект. Для него это 3 меша с 2 текстурами на каждом, и он говорит GPU: «здесь 9 штук надо отрендерить». Так что вместо того чтобы модель персонажа была единым мешем с двумя текстурами, у неё три меша с шестью текстурами в совокупности. На наших глазах у нас утроилось количество вызовов отрисовки на одну модель. И это самая медленная часть рендеринга 3D графики, её узкое горлышко. Настолько медленная, что соверменные движки выгружают как можно больше в GPU, чтобы CPU не тратило время на вызовы отрисовки. Современные CPU, кажется, ограничены около 10 тысячами вызовов отрисовки перед тем как FPS упадет ниже 60. Однако больше вызовов отрисовки не означает падение FPS в ноль. Чейдинхол вызывает около 46 тысяч вызовов отрисовки, но 30 FPS вполне способен удержать, в то время как 20 тысяч вызовов отрисовки из RAEVWD не могут стабильно выдавать даже 25 ФПС. Это раазница, которую нужно держать в уме. Смотрите на вызовы отрисовки в конкретной области, а не в игре в целом. тестирование Сперва я создал HUD чтобы отражать информацию, которую я хочу видеть. Используя Линукс и AMD GPU, я перешел на Gallium, используя Gallium New драйвер в виде аддона для игр на Wine. Это дало мне информацию по каждому ядру CPU, FPS, загрузке GPU, и количеству вызовов отрисовки. Первые мысли Изначально я был убежден, что собака зарыта в освещении (lights). Я тестил стартовую ячейку в тюрьме и думал, что источники света вызывают около 1500 отрисовок. Это, мягко говоря, многовато для света. Поэтому я пошел в Чейдинхол и повозился с освещением у Западных Ворот, быстро выяснив, что дело не в источниках света. Их отключение ни к чему не привело! Ясно, что я иду в неправильном направлении. Вот так выглядит интерфейс исследования оптимизации Следующая мысль Тогда я решил, что проблема в домах. Я уже знал, что они сделаны неэффективно. Поэтому я протестил дома и отключил их. И увидел, что количество вызовов отрисовки падает в разы! 5000 вызовов отрисовки тут же пропали. Тогда я решил сделать нечто еще более радикальное и удалил пачку домов рядом с собором и снова потестил область. Почти 20 тысяч вызовов отрисовки тут же испарились. Проблема была ни в источниках света, ни в ЛОДах. Виноваты дома Чейдинхола! С источниками света Без источников света С домами Без домов С домами Без домов обливион и вызовы отрисовки Обливион разработан для ПК и Xbox360 соответственно. По правде кое в чем он разрабатывался в первую очередь под Xbox360. У консоли было только 512 МБ памяти для работы на всю систему, когда как самый скромный ПК скорее всего имел 1 ГБ системной памяти и 256 МБ видеопамяти в то время. К тому же игра была создана под один двухслойный диск DVD (содержит около 8 ГБ). Бесезда должна была минимизировать размеры текстур, при этом не делая из игры заблюренную кашу. Чтобы добиться этого они создали  текстуры по единому образцу (generic textures) для общих мешей по единому образцу (generic meshes), чтобы состыковать кусочки мешей вместе и сделать тем самым модель. Эти меши так же соединялись по единому образцу при создании новых строений. Они не могли добиться того чтобы в игре были один меш с одной-двумя текстурами на модель, это бы съело слишком много места на диске и в памяти. Типичный дом в Чейдинхоле имеет следующую модель: Каждый NiTriStrips имеет соответствующую текстуру, и эта текстура должна иметь соответствующую карту нормалей. Это около 50 вызовов отрисовки на дом. А у нас десятки домов перед глазами единовременно. И Обливион не имеет Occlusion Culling, так что все эти дома рендерятся всегда, когда находятся перед глазами. Так что неудивительно, что Чейдинхол не шибко оптимизирован. Данные из Nifskope математическая проблема Если сложить в уме, то окажется, что 50 вызовов отрисовки на дом не могут привести к 46 тысячам вызовам отрисовки в Западных Воротах. Честно? Я тоже не знаю, как это работает. Очень сложно определить, что именно требует вызова отрисовки, особенно, когда у нас нету SDK движка. Если у кого есть более продвинутые познания, я бы мечтал узнать об этом от вас. решение Пока что есть только одна вещь, фиксящая проблемы вызовов отрисовки в Обливионе, и она не самая простая в реализации. Все статичные модели игры (камни, здания, и тд) нужно переделать в единый меш с использованием атласной текстуры. Морровинд имеет восхитительный проект Атласного Текстурирования, который включает все модели игры и комбинирует компоненты мешей в единую модель. Если сделать нечто подобное для домов в Чейдинхоле, то вместо 50 вызовов отрисовки на один дом у нас будет около 3,6% вызовов отрисовки от этого числа. Я бы потестил это сам, но не умею моделировать, да и времени учиться этому нет. VWD opitimized meshes qwertyasdfgh’а это отличная точка отчета, но это только для ЛОДов. Как по мне нам нужен проект, который включит в себя все оригинальные меши. В таком случае даже оригинальные VWD меши будут хорошо оптимизированы. Как мне кажется, это единственный способ сделать Обливион оптимизированным в ближайшем будущем, особенно с учетом порта на OpenMW, который появится лет через 5 минимум, и тем, что Борис не вернется в Обливион чтобы дать нам Occlusion Culling. Тогда проблема Чейдинхола наконец-то будет решена.