werr

Ограничение 15 минут))

ИТОГИ КРУГЛОГО СТОЛА MICROSOFT И BETHESDA youtu.be/va0mI2VeD6s

Помимо стандартного фолловерского квеста, Серана применяет две хитрости. Вернее два квеста: DLC1NPCMentalModel и DLC1NPCMonitoringPlayer. Эти два квеста работают в связке, но если интересует ее сэндбокс поведение, то вам во второй квест, в скрипт DLC1NPCMonitoringPlayerScript. Если по-простому, то Серана постоянно следит за игроком и раз в секунду запоминает его положение в пространстве в виде массива за последние восемь секунд. Дальше начинаются опции: Серана подсчитывает длину вектора смещения игрока, и если за это время игрок не ушел от своего начального места (или отошел, но вернулся) на расстояние, что Серана считает допустимым (ну то есть 150 единиц, ага), -- значит можно врубать сэндбокс из квеста DLC1NPCMentalModel. Делается это просто изменением QuestVariable (разные значения которых стоят в качестве кондишенов у разных пакетов). Ну и поскольку игра в фоновом режиме не очень шустро пересматривает стак АИ пакетов (а за это время ситуция с игроком может уже сто раз измениться), то можно еще и попросить ее это сделать принудительно через AliasProperty.GetActorReference().EvaluatePackage(). П.С. В общем тут Серана бдит прямо как в жизни за своим мужиком: куда пошел, с кем и что делает? Может лучше не надо никаких "умных" фолловеров, чтобы хотя б в игре без этого было?

-2021й год. Тодд, а ты так и не изобрел ничего лучше Скайрима. -А кто изобрел?

В том, что ты неправильно настроил АИ пакеты. Например неправильный кейворд LinkedRef-у выставил, и поэтому пакет не срабатывает. Все пакеты, которые ты на скрине показал - дефолтные. Сомневаюсь, что ты правильно настроил НПС при этом. Сами по себе они работать не будут. А дальше происходит то, что при заказе песни у твоего барда, его ObjectReference заполняется в элиас квеста, который управляет бардами. После чего у элиаса все время активен только один пакет, который и заставляет его выступать. Настрой своего НПС точнее.

Игра не непрерывно смотрит на текущие аи пакеты, поэтому быстрее будет заставить ее принудительно перепроверить стак пакетов. Если дело действительно в стаке (исходя из того, что ты написала) ObjectReferencePropertyREF.GetActorReference().EvaluatePackage()В общем EvaluatePackage() на актера вызывается.

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

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

Очень может быть. Ну тогда решением проблемы может стать создание какой-нибудь фракции (да или даже PlayerFaction взять как вариант), которой будет принадлежать Ownership всех стульев, кроватей, алхимических столов и других маркеров. А когда же тебе будет нужно по квесту, чтобы у НПС туда был доступ, будешь скриптом выдавать им эту фракцию. Так игра разрешит их пакетам юзать эти объекты.

Звучит довольно нелогично, потому что когда ячейка прогружена, актер (дракон) спокойно может использовать маркеры; а когда нет - то и самого актера нет. Хотя драконами я никогда не интересовался, поэтому категорично утверждать не стану.   Хмм... А ты это точно на чистом сохранении пробуешь? Прямо из главного меню через "coc id локации" или "cow Tamriel X Y" телепортируешься свежим персонажем?

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

Навмеши на земле. В воздухе маркеры (Xmarker либо XmarkerHeading). Если у них стоит галка Sky Marker, то от них вертикально вниз идет синяя линия, что помогает визуально сориентироваться, куда этот маркер на земле попадает. Игра не знает ничего про высоту и поэтому навмеши можно располагать на любой горизонтальной поверхности, обычно они постелены просто по геометрии локации.

Я щяс проверил, в ответе ранее я не совсем верно указал насчет дебаггинга освещенности. Кнопка "7" просто включает/отключает отрисовку в режиме wireframe. Дебаг света можно провести так: ПКМ в окне рендера - Render Window Properties - Shaders. И в секции Debug поставить галку напротив # of lights, затем нажать Apply. Вот теперь в цвете видна нагрузка света на локацию. Если какие-то меши горят красным - освещение в игре будет лагать. Соотвественно чтобы в редакторе все это дело нормально отслеживать, нужно, чтобы кнопка FX (Animate Lights and Effects) была прожата.

Драконы (они же вертиберды в фоллауте) - это отдельная телега. Они летают и им нужны особые маркеры. Как правило драконы используют дефолтный драконий AI пакет, который заставляет их искать эти особые маркеры и кружить вокруг их. Нужно расположить Xmarker/XmarkerHeading в воздухе и во вкладке Extra отметить, что он Sky Marker. Дальше можно из них составлять маршруты разнообразные как с патрулированием у обычных гуманойдных НПС. Не забудь только перефинализировать навмеши. Без этого драконы будут летать как угодно через стены и коллизии. Касательно второго вопроса, проще всего поместить коллижн-бокс и в настройках в разделе Primitive поменять ему тип взаимодействия с окружением на L_NAVCUT. Такой бокс будет "отсекать" навмеши, что попадают в его область действия (как в триггер). Таким образом НПС не будут видеть навмеши в определенной области и не смогут пройти туда. Затем скриптом этот бокс можно энейблить/дизейблить.

Хмм, ок. Почему-то я был уверен.

Это делается шейдерами (EffectShader). А SetAlpha(), к слову, в Скайриме может принимать значения 0 или 1. Промежуточные значения округляются до 1.

На интерьер, да.

    За это отвечает параметр Shadow Depth Bias в настроках Light Data у референса в окне рендера. Исходно он равен 1. Что многие мододелы не понимают – это то, что недостаточно просто расставлять лампочки на уровне, нужно настраивать и этот параметр. Проще всего его прожать по-умолчанию (кнопка Default). Так же стоит отметить, что благодаря девятому ДиректХ, Creation Engine версии Скайрима может нормально обрабатывать только до 4 источников света типа _Shadow. А вообще вроде бы кнопка "7" включает/отключает панель, в которой видна нагрузка источников света на меши моделей. Если какая-нибудь область горит красным, то с такой поверхности может спонтанно целиком пропадать освещенность. Тогда надо будет передвигать источники света так, чтобы контуры сфер/конусов (которпые обозначают область действия источников освещения) не заходили на проблемную меш.   Объяснил как мог.  

Я добавлю к тому, что написал Azazellz. Выставление владельца целой ячейки не должно влиять на владельца отдельных предметов, у которых в настройках установлен другой хозяин. Если нужно, чтобы у ряда объектов в скопированной ячейки был другой владелец, то гораздо удобнее это сделать через Reference Batch Action menu. Выдели все желаемые предметы, вызови окно Batch menu кнопкой "-", там в поле Set Owner выставь владельца этим вещам, нажми Do. Это применит данное изменение всем выделенным ObjectReference-ам.

Карта мира в игре состоит из ЛОДов земли/объектов самого последнего уровня (3й что ли) и создается автоматически при их генерации. При этом в папке .\textures\terrain\tamriel находятся сгенерированные текстуры по ячейкам - DXT1 128x128. Если тебе нужно прорисовать по имеющейся карте дороги, то нужно в фотошопе сделать коллаж цельной карты из сгенерированных фрагментов, нарисовать дороги и пересохранить оригинальный набор картинок. Если делаешь свой мир, то в каком-то смысле проще для текстур, которыми красишь области под дорогами, выбрать что-нибудь более броское (например карту нормалей посильнее). Так при генерации ЛОДов карта твоего мира естественным образом будет содержать визуально выделяющиеся области. Альтернативно, в настройках ворлдспейса можно выставить картинку (DDS текстура), которая будет отображаться вместо карты.   Можно. Правда если нужна погода внутри такого пространства, все равно придется делать ворлдспейс. Нет, конечно можно скриптами зафорсить погоду внутри интерьера, но это лишний и нестабильный гемор.

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

Ну если я правильно помню, терминалы в игре заведомо приподняты относительно пола на высоту стола (все столы в игре одной высоты на самом-то деле), чтоб на них размещать. Плюс к ним маркер гуманоида прикреплен, показывающий, какую позу НПС займет при активации терминала. Так что наверное такое дизайнерское решение оправдано.

Взрыв применяется не на саму меш терминала, а на якорную точку (pivot point) - то место, где в редакторе желтое перекрестье у основании любого объекта, помещаемого в Render Window. Если бы мне нужно было сделать задуманное, то я бы помещал Xmarker через PlaceAtMe() как ты это и делаешь, потом двигал бы маркер вверх (это где-то 64 единицы навскидку) и все тем же пресловутым PlaceAtMe() размещал взрыв по Xmarker-у. Ну и удалить этот маркер в конце было бы не лишним.

Черт... Зря я что ли Kingdom cum по скидке на новогодние праздники купил?

Хеор, сформулирую иначе: Если VTMB2 - выйдет годным, какая разница, что с этой игрой.